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
