| Subject | Re: [firebird-support] Re: Lost connection to firebird after execute procedure |
|---|---|
| Author | Helen Borrie |
| Post date | 2004-12-06T10:09:30Z |
At 08:54 AM 6/12/2004 +0000, you wrote [at the end of a great big mess]:
How can you expect to get a useful answer from such messy, untrimmed messages?
This is the error code being reported by the monitor in this snippet:
occur on the second invocation. Previously you said you were getting
335544384, which is an internal bad block error, not once that an
application should see. So - have you a different message file now?
About all I can guess from this is that, previously, you clients were
running an old client that had access to a wrong message file.
Some more thoughts...
1. Your SP's first input parameter (presumably a string) is weird. It
looks like this:
'101,201 0000000044 ,201 00667 ,201
0987654321 ,201 100 ,201 5260210429 ,201 6840019862,201
5272098665,201 8133196354'
What happens to this string when it reaches the stored procedure? Could
there be some bad parsing going on, that is delivering the wrong inputs to
another procedure call?
2. Your query gives me a headache just looking at it. Not only are you
joining a SP with a table, and adding an ORDER BY that involves one field
from the SP output and one from the table, but you are using the old SQL-89
implicit join syntax. Maybe you haven't declared the JoinLinks in your IBO
query object, either. This is something you must do if you insist on using
implicit join statements.
3. Considering the symptoms, you seem to be seeing another old IB 5.5/IB 6
client bug that leads me to suspect that your application is using the
IB.version of gds32.dll. You can work around this by explicitly calling
Unprepare on the SP after *each* call and then calling Prepare explicitly
before executing it again. But in fact you should get rid of that old
client. Make sure that your application is loading the client version that
you think it is. Check to make sure you do not have that old client
sitting in the path somewhere.
A reality check you can do is to run the application on the client machine
that is causing the trouble, then go to the gds32.dll that you *believe* is
loaded, and try to rename it. If you can rename it, then the application
is using some other client library.
4. In any case, check the version strings of the gds32.dll files on the
client machines. If the 3- or 4-digit build number doesn't match that of
the server, then you have the wrong client.
Other than that, who really knows? Sorry, it defeats my E.S.P.
./hb
> Thank You very much. It is always great to read Your answers on thisWojtek
> group. Maybe You can tell me something helpfull after my post?
How can you expect to get a useful answer from such messy, untrimmed messages?
This is the error code being reported by the monitor in this snippet:
>EXECUTE STATEMENTIt is not the same error code you reported before and said would always
>TR_HANDLE = 34832852
>STMT_HANDLE = 34942616
>PARAMS = [ ]
>
>SECONDS = 0.561
>
>ERRCODE = 335544721
>----*/
>/*---
>INTERPRETE BUFFER =
>
>ERRCODE = 53
>----*/
>/*---
>INTERPRETE BUFFER = Unable to complete network request to host "top-
>sql".
>
>ERRCODE = 39
>----*/
>/*---
>INTERPRETE BUFFER = Error reading data from the connection.
>
>ERRCODE = -1
occur on the second invocation. Previously you said you were getting
335544384, which is an internal bad block error, not once that an
application should see. So - have you a different message file now?
About all I can guess from this is that, previously, you clients were
running an old client that had access to a wrong message file.
Some more thoughts...
1. Your SP's first input parameter (presumably a string) is weird. It
looks like this:
'101,201 0000000044 ,201 00667 ,201
0987654321 ,201 100 ,201 5260210429 ,201 6840019862,201
5272098665,201 8133196354'
What happens to this string when it reaches the stored procedure? Could
there be some bad parsing going on, that is delivering the wrong inputs to
another procedure call?
2. Your query gives me a headache just looking at it. Not only are you
joining a SP with a table, and adding an ORDER BY that involves one field
from the SP output and one from the table, but you are using the old SQL-89
implicit join syntax. Maybe you haven't declared the JoinLinks in your IBO
query object, either. This is something you must do if you insist on using
implicit join statements.
3. Considering the symptoms, you seem to be seeing another old IB 5.5/IB 6
client bug that leads me to suspect that your application is using the
IB.version of gds32.dll. You can work around this by explicitly calling
Unprepare on the SP after *each* call and then calling Prepare explicitly
before executing it again. But in fact you should get rid of that old
client. Make sure that your application is loading the client version that
you think it is. Check to make sure you do not have that old client
sitting in the path somewhere.
A reality check you can do is to run the application on the client machine
that is causing the trouble, then go to the gds32.dll that you *believe* is
loaded, and try to rename it. If you can rename it, then the application
is using some other client library.
4. In any case, check the version strings of the gds32.dll files on the
client machines. If the 3- or 4-digit build number doesn't match that of
the server, then you have the wrong client.
Other than that, who really knows? Sorry, it defeats my E.S.P.
./hb