On Tue, Jan 19, 2010 at 11:06 AM, m. allan noah <[email protected]> wrote: > On Thu, Jan 14, 2010 at 7:41 PM, Jonathan Leffler > <[email protected]> wrote: >> On Thu, Jan 14, 2010 at 8:49 AM, m. allan noah <[email protected]> wrote: >>> >>> I have a problem with some fastcgi scripts which use DBD::Informix. >> >> I trust this is DBD::Informix 2008.0513 and not some earlier version. > > correct. > >> Which version of Perl are you using? > > 5.8.8 (IA64.ARCHREV_0-thread-multi-LP64) > >> Which platform are you running on? > > HPUX 11.31 Itanium > >> Which version of Informix ClientSDK (ESQL/C) are you using? > > esql -V > IBM Informix CSDK Version 3.50, IBM Informix-ESQL Version 3.50.FC3 > >>> Fastcgi is like regular cgi, except the script does not exit after the >>> request is complete, it loops back to the beginning, and waits for a >>> new request. This significantly improves performance for scripts with >>> large startup penalties. The scripts are single threaded, with apache >>> spawning new copies as required. >>> I am connecting and disconnecting from the db on each request. >>> >>> Everything works fine, except that sql error messages can only be >>> found on the first pass thru the fastcgi loop. e.g. >>> >>> DBD::Informix::st execute failed: SQL: -268: Unique constraint >>> (informix.u116_31) violated. >>> ISAM: -100: ISAM error: duplicate value for a record with unique key. >>> >>> On the subsequent passes i get: >>> >>> DBD::Informix::st execute failed: SQL: -268: <<Failed to locate SQL >>> error message>> >>> ISAM: -100: <<Failed to locate ISAM error message>> >> >> I've not seen that behaviour before that I recall. >> >> How reliable is it? 100%? Sometimes? Seldom but often enough to be >> annoying? > > 100% reliable. The first pass thru the loop has access to the > messages, all subsequent passes do not. This happens even if the first > pass does not generate an error. > >>> I have dumped the environment on both passes, and they are identical, >>> including all the informix vars. I cannot reproduce this issue with a >>> command line script, so I might have to ask some apache/fastcgi >>> hackers too, but I thought I would start here. >> >> Normally, once the code has found the error messages once, there is no >> further problem. It is very unusual - indeed, I'm not sure I have any >> explanation of a mechanism by which it can happen. > > I've also used Env::C to dump the 'C' environment, and those vars are > also the same on each pass. I'm at a loss otherwise. > >> The best I can come up with as a 'debugging' mechanism is to suggest that >> you add tracing to the system - DBI_TRACE=3 (or higher) in the environment >> or an equivalent. Offhand, I'm not sure where the output would go with >> FastCGI in the system; you might need to work on the output file too. > > I will try this and report back.
And, setting $dbh->trace(10,'/tmp/foo') yields the same output for both passes, with the exception of the error messages. I'm left scratching my head here, but I'll keep trying to reproduce it at the command line. allan -- "The truth is an offense, but not a sin"
