On Sun, Jun 10, 2007 at 03:00:56PM -0700, Jonathan Leffler wrote:
> Consider the code:
>
> #!/bin/perl -w
> #
> # Does DBI mishandle disconnected handles?
>
> use strict;
> use DBI;
>
> my $dbh = DBI->connect('dbi:Informix:stores', '', '', {RaiseError=>1});
>
> my $st1 = $dbh->prepare(qq{SELECT * FROM SysTables});
>
> $dbh->disconnect;
>
> # Shouldn't DBI error here?
> $st1->execute();
>From the DBI's perspective it's up to the driver to decide how to handle it.
>From the driver's perspective it's often left to the underlying database
API to report an error.
That's generally the best approach. It's reasonable for statement
handles to remain 'as functional as possible' after a disconnect.
If the execute() call of the underlying db API doesn't report an error
when the connection has been disconnected I'd call that a bug in the
underlying db API (or at least a mis-feature).
> # Shouldn't DBI error here?
> my $st2 = $dbh->prepare(qq{SELECT * FROM SysTables});
>
> print "Oops - I don't think you should have seen this!\n";
> exit 1;
>
>
> Using DBD::Informix as above, I get the "I don't think you should have seen
> this" message, but I think that the attempt to use $st1 should have been
> headed off long before it got to calling DBD::Informix code because the
> relevant database handle was disconnected, so there should be nothing that
> can be done with it (either the $dbh or $st1). I was using DBI 1.53-1.56 on
> various machines with Perl 5.8.8 - various variants.
>
> I would expect that any use of a statement handle such as $st1 should fail
> after the parent $dbh has been disconnected.
I would expect that any use of a statement handle *that required a
working database connection* should fail (at the database API level).
> Is the reason it doesn't something to do with caching - of connections or
> statements?
I don't think so. The bottom line is that it's up to the driver and the
underlying database API.
Tim.
