On Tue, Mar 25, 2008 at 09:31:30AM +0100, Mark Lawrence wrote:
> I'm having a problem with one of my modules (SQL::DB) failing on
> calls to prepare_cached. I'm asking here for help because this is
> failing on every CPAN Tester's build, but I can't repeat the issue
> locally (x86_64 Debian). The tests use SQLite for the database.
>
> The error is occuring on INSERT and UPDATE statements:
>
> t/09-db...........prepare_cached(INSERT INTO
> sqldb (name, val)
> VALUES
> (?, ?)
> ) statement handle DBI::st=HASH(0xdf1cd8) still Active at ...
>
> As far as I know I am not nesting calls to the same statement. But even
> if I was, what I don't understand is how an INSERT or UPDATE statement
> handle remains active after the database call. According to the pod:
>
> "Active" (boolean, read-only)
>
> The "Active" attribute is true if the handle object is "active". This
> is rarely used in applications. The exact meaning of active is somewhat
> vague at the moment. For a database handle it typically means that the
> handle is connected to a database ("$dbh->disconnect" sets "Active"
> off). For a statement handle it typically means that the handle is a
> "SELECT" that may have more data to fetch. (Fetching all the data or
> calling "$sth->finish" sets "Active" off.)
>
> I know about the $if_active option to prepare_cached, but I would rather
> get the warnings and I don't want new statement handles added to the
> cache for what I believe is the same statement.
You're right that INSERT or UPDATE statements shouldn't have Active set.
I'd start by trying to understand how/why/where that's happening.
> I have other question: The call to prepare_cached is happening
> inside two eval{} blocks, yet the error message above doesn't come from
> my code but instead from DBI.
I'm not quite sure what you're saying here, but the warning is generated
by prepare_cached() in DBI.pm using carp().
> I'm also really curious why I can't repeat
> this behavour on my machine, but *every* CPAN tester sees this result.
There's always an answer, you just have to dig deep enough to find it.
Perhaps you're using a different version of some key module(s), like
DBD::SQLite.
Tim.
