On Fri, Sep 22, 2006 at 01:37:42PM -0700, Philip M. Gollucci wrote: > Hi, > > I've a several 100 thousand line application. I did not introduce this > issue, but I need to fix it. > > prepare_cached(SELECT foo FROM A where X = ?) > statement handle MyDBI::st=HASH(0xd630194) was still active at X.pm > > I've tried turning on $dbh->(12, 'file.trace') and looking for all things > that shared the statement handles > address. Then seeing if there was a FETCH= undef -- the end of a while > loop, or finsih= 1 -- $sth->finish() was called. > > That took a long time and everything seemed okay. Then I pains-takenly > figured out all the 'prepare_cached' involved in the code path. I then add > $sth->finish() for kicks everywhere even when I knew I "didn't need it" per > the DBI docs about it. This didn't help. > > Is there any way (preferably easy) to track this down ? > > Its going to have to programatic as the amount of code involved is not > manageable and I'm unable to reduce it. If I could reduce it I could fix > it :)
I'd focus on the particular SQL statement reported in the message. I presume you'd be able to identify where that SQL statement was in the code (or where it was generated). Then $sth->trace() just that handle. But the way you were doing it should have found the problem. Get a trace then grep it for the particular handle address you're interested in. A more exotic approach might be to subclass the DBI and override the execute method, for example, to store a copy of the call stack into a private attribute of the handle. Then add an error handler that dumps that info if it's present. Then your error message might say something like "... was still active (last executed at file Foo.pm line N called by Bar.pm line M)" etc etc. Tim.
