Tim Bunce wrote:
I just ran into this problem...
A stored procedure call like "exec foo ..." was appearing to succeed but
returning no data.
It turned out that the ASE (15.0, which we've recently upgraded to) was
terminating the backend process (not sure why yet) but DBD::Sybase 1.08
wasn't noticing it.
Here's the trace:
-> execute for DBD::Sybase::st (DBI::st=HASH(0x2a995b0360)~0x2a995b04b0)
syb_alloc_cmd() -> CS_COMMAND 294e7e0 for CS_CONNECTION 294b8e0
cmd_execute() -> ct_command() OK
cmd_execute() -> ct_send() OK
cmd_execute() -> set inUse flag
servermsg_cb -> number=5702 severity=10 state=1 line=2 server=dev_barbie01
text=ASE is terminating this process.
st_next_result() -> ct_results(4047) == 1
st_next_result() -> ct_results(4046) == 1
ct_results(4046) final retcode = -205
st_next_result() -> lasterr = 0, lastsev = 0
st_next_result() -> got CS_CMD_DONE: resetting ACTIVE, moreResults,
dyn_execed, exec_done
clear_sth_flags() -> resetting ACTIVE, moreResults, dyn_execed, exec_done
clear_sth_flags() -> reset inUse flag
<- execute= -1
<- $DBI::err= undef
<- $DBI::errstr= 'Server message number=5702 severity=10 state=1 line=2 server=dev_barbie01 text=ASE is terminating this process.'
Notice that although errstr contains the error message, err is undef.
This error happens when there is a stack trace on the server side
(infected with 11, or similar) where ASE has to terminate the
connection. It's an indication of a bug in ASE.
The next time the connection was used it would fail with "Message String: ct_send():
network packet layer: internal Client Library error: State error: trying to write when
connection is expecting a read."
I've appended a patch that seems to fix the problem, but I don't know if
it's doing the right thing in the best way. For example, I tried
adjusting the "severity > 10" to "severity >= 10" in the code below
but that caused some tests to fail.
Normal - there are other severity 10 errors that are not fatal or even
errors as such. Actually I'm surprised that the 5702 error is only a 10,
but I guess this will also be delivered when a DBA kills the connection
from the server side (kill <spid>), and that might not be rated as a
really serious issue.
Michael, any chance you could review this and get it (or a better fix)
released soonish?
The fix looks reasonable, but I think what you are seeing might be an
indication of a deeper problem when the connection is abruptly lost.
Normally the connection should be marked "dead" in this condition, and
DBD::Sybase should detect it.
Michael
--
Michael Peppler - Peppler Consulting SaRL
[EMAIL PROTECTED] - http://www.peppler.org
Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com
Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
