I have traced it back to prepare_cached() (at least that is what I
notice).
Scott, try replacing your calls on startup with prepare() instead of
prepare_cached().
I was also able to eliminate the problem if I commented out the
following line in DBI.pm
# $dbh->STORE('CachedKids', $cache = {}) unless $cache; # line 1021
sub prepare_cached
Of course this is not a solution, but it may give someone else with more
knowledge enough to fix the problem. I will keep digging for answers.
--eric
"Scott R. Godin" wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Eric Kolve) wrote:
>
> > I think I have found a curious bug in DBI. It seems that since DBI 1.15
> > - 1.20, when you bring up apache/mod_perl and execute queries against
> > the database handle in the parent process (startup.pl), multiple
> > connections result against the database. If I switch to DBI 1.14, no
> > such problem occurs. I have found this problem occurs with:
> >
> > DBI 1.20 + DBD::Oracle 1.12
> > DBI 1.15 + DBD::Oracle 1.07
> > DBI 1.16 + DBD::Oracle 1.07
> >
> >
> > I have turned on Apache::DBI::DEBUG and trace(2) in DBI. Could someone
> > tell me what I should be looking for or can someone else shed any light
> > on this? I am not sure if this is necessarily a mod_perl issue or if
> > mod_perl is just eliciting a bug in DBI.
> >
> > thanks,
> >
> > --eric
>
> I've noticed this too, and it has *seriosly* damaged any credibility I
> might have gained with the admin I'm up against who is a major PHP
> proponent, and who refused to even think about installing mod_perl to
> help the script along after he saw this. :/
>
> --
> Scott R. Godin | e-mail : [EMAIL PROTECTED]
> Laughing Dragon Services | web : http://www.webdragon.net/
