On Thu, 2004-11-25 at 09:39, Henri Asseily wrote: > > That *might* be a problem with DBD::Sybase and/or with the way Sybase > > client libs use signals. > > > > As Lincoln suggested, a couple of traces might be useful. > > I'm running under mod_perl, DBI 1.45 and DBD::Sybase 1.04. I'm > attaching a number of traces.
> Now below is what happens when a timeout is caught and the execution is > stopped by the signal: > > DBIx::HA::st=HASH(0x832d4c0) trace level set to 0x0/15 (DBI @ > 0x0/0) in DBI 1.45-nothread (pid 20784) > -> execute for DBD::Sybase::st > (DBIx::HA::st=HASH(0xad1a364)~0x832d4c0) > syb_alloc_cmd() -> CS_COMMAND 80af758 for CS_CONNECTION 8f4f2e0 > syb_st_execute() -> ct_command() OK > syb_st_execute() -> ct_send() OK > < HERE THE EXECUTION TIMES OUT AND IS STOPPED BY THE SIGNAL > > -> finish for DBD::Sybase::st > (DBIx::HA::st=HASH(0xad1a364)~0x832d4c0) > syb_st_finish() -> flushing > (in cleanup) dbih_setup_fbav: invalid number of fields: -1, > NUM_OF_FIELDS attribute probably not set right at /xxx/xxx/xxx.pm line > 207. OK - that one's pretty obviously a bug - where the destroy tries to flush (fetch) all the results, but the result structure hasn't been set up. Tim may be correct that the "active" flag is being set too early on the handle - I'll take a look at the sequence again. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.peppler.org/ Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.peppler.org/resume.html
