On Fri, 2006-09-22 at 13:37 -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 :)
What database and DBD are you using? There has been a bug in recent versions of DBD::mysql (fixed in 3.0007) that was producing these errors. mark -- MARK ADDISON WEB DEVELOPER 200 GRAY'S INN ROAD LONDON WC1X 8XZ UNITED KINGDOM T +44 (0)20 7430 4678 F E [EMAIL PROTECTED] WWW.ITN.CO.UK Please Note: Any views or opinions are solely those of the author and do not necessarily represent those of Independent Television News Limited unless specifically stated. This email and any files attached are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify [EMAIL PROTECTED] Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read messages sent to and from our systems. Thank You.
