On Sat, Jan 04, 2003 at 12:38:08PM +1100, Steve Baldwin wrote:
> How about simply displaying the {Statement} attribute in the message.
> At least that would assist in tracking it down.
>
> Do you think that would be easier to code ?
The dbh warning message can't show the {Statement} attribute of
it's child sth's because it doesn't keep a copy of the references.
If it did there would be a reference loop.
An alternative would be to include the {Statement} attribute of an
sth in the trace log when it's DESTOY'd. That would be easier to code.
Tim.
> -----Original Message-----
> From: Tim Bunce [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, 4 January 2003 11:13 AM
> To: Steve Baldwin
> Cc: [EMAIL PROTECTED]
> Subject: Re: Detecting active statement handles
>
>
> On Sat, Jan 04, 2003 at 07:53:20AM +1100, Steve Baldwin wrote:
> > I assume this is the sort of thing you're talking about ...
> >
> > -> DESTROY for DBD::Oracle::st (DBI::st=HASH(0x105ec244)~INNER)
> >
> > I'm not sure how this helps me. I can see a statement handle is being
>
> > destroyed, but how do I get more info on which one it is ?
>
> Look back in the trace for the most recent prepare/execute
> returning/using that handle (0x105ec244).
>
> > Given that {CachedKids} already returns a hash to cached statement
> > handles, how about allowing {Kids} and/or {ActiveKids} return an array
>
> > if being invoked in list-context ? Let me know if you think this is
> > worthwhile - maybe I could have a crack at coding this myself.
>
> It would create a reference loop. I do plan to explore using 'weak refs'
> at some point to avoid the reference loop problem.
>
> You're most welcome to have a crack at coding that. See sv_rvweaken() in
> 'perldoc perlapi'. Shouldn't be too hard.
>
> Tim.
>
