prepare_cached and Apache::DBI.

[Paul Sullivan <pa...@thinkgeek.com>]

When attempting to use prepare_cached along with Apache::DBI, it 
returns this error once it has ran through each of the apache 
children.

[Wed Apr  5 ...] [error] prepare_cached(...) statement handle 
DBI::st=HASH(0x8296788) is still active at /home/... line ...

Is prepare_cached not recommended for use with mod_perl? If not, 
would could I possibly to do to correct the above error.

TIA :)
-- 
--------------
Paul Sullivan
Senior Programmer
Andover.Net
http://www.andover.net/
--------------

[End of diatribe.  We now return you to your regularly scheduled 
programming...]
     --Larry Wall in Configure from the perl distribution

Re: prepare_cached and Apache::DBI.

[Sean Dague <se...@dague.net>]

> > When attempting to use prepare_cached along with Apache::DBI, it 
> > returns this error once it has ran through each of the apache 
> > children.
> > 
> > [Wed Apr  5 ...] [error] prepare_cached(...) statement handle 
> > DBI::st=HASH(0x8296788) is still active at /home/... line ...
> 
> You should only be getting that error if there is more data on that
> statement handle that you haven't read.  You can take care of that by
> calling $sth->finish, or by reading the rest of the data.
> 
> - Perrin

I was getting similar errors when using the RaiseError flag under DBI as
suggested by the perldoc.  Posted to dbi-users, and turns out that this is
a known issue that will be fixed in an upcoming DBI release.

As a workarround code something like this should help (if you are using
RaiseError => 1):

eval {
	bunch of sqlstatments
}
if($@) {
	foreach $handle (keys $dbh->{CachedKids}) {
	    $handle->finish();
	}
}

Hope this is useful.

	-Sean

-- 
Sean Dague
sean@dague.net

There is no silver bullet.  Plus, werewolves make better neighbors than
zombies, and they tend to keep the vampire population down.

Re: prepare_cached and Apache::DBI.

[Perrin Harkins <pe...@primenet.com>]

On Wed, 5 Apr 2000, Paul Sullivan wrote:

> When attempting to use prepare_cached along with Apache::DBI, it 
> returns this error once it has ran through each of the apache 
> children.
> 
> [Wed Apr  5 ...] [error] prepare_cached(...) statement handle 
> DBI::st=HASH(0x8296788) is still active at /home/... line ...

You should only be getting that error if there is more data on that
statement handle that you haven't read.  You can take care of that by
calling $sth->finish, or by reading the rest of the data.

- Perrin

Re: prepare_cached and Apache::DBI.

["Jeffrey W. Baker" <jw...@acm.org>]

On Wed, 5 Apr 2000, Paul Sullivan wrote:

> When attempting to use prepare_cached along with Apache::DBI, it
> returns this error once it has ran through each of the apache
> children.
> 
> [Wed Apr 5 ...] [error] prepare_cached(...) statement handle
> DBI::st=HASH(0x8296788) is still active at /home/... line ...
> 
> Is prepare_cached not recommended for use with mod_perl? If not, would
> could I possibly to do to correct the above error.

You could start by R'ing TFM.  This from perldoc DBI:

prepare_cached

             $sth = $dbh->prepare_cached($statement)
             $sth = $dbh->prepare_cached($statement, \%attr)
             $sth = $dbh->prepare_cached($statement, \%attr,
$allow_active)

           Like the prepare entry elsewhere in this
           document except that the statement handle returned will
           be stored in a hash associated with the $dbh. If
           another call is made to prepare_cached with the same
           parameter values then the corresponding cached $sth
           will be returned without contacting the database
           server.

           This caching can be useful in some applications but it
           can also cause problems and should be used with care.
           A warning will be generated if the cached $sth being
           returned is active (i.e., is a select that may still
           have data to be fetched) unless $allow_active is true.

           The cache can be accessed (and cleared) via the the
           CachedKids entry elsewhere in this documentattribute.


If you don't want the warning, you need to pass a true value as the
third argument to prepare_cached.

As usual, I recommend caching the database handles yourself in global
scalars somewhere, as calling the prepare_cached method has significant
overhead and is only slightly easier to use than doing it yourself.

-jwb