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. Thanks! allan -- "The truth is an offense, but not a sin"
