DBD::mysql 3.0004+ not resetting $sth->{Active} after fetch

DBD::mysql 3.0004+ not resetting $sth->{Active} after fetch

am 22.06.2006 15:27:25 von Mark.Addison

Hello,

I upgraded DBD::mysql from 2.9006-1 to 3.0006-1 and suddenly started
getting
screens full of errors like:

prepare_cached(SELECT * FROM foo) statement handle
DBIx::ContextualFetch::st=HASH(0x971cc80) still Active at
/usr/share/perl5/Ima/DBI.pm line 381

After some digging it seems that the new version of the DBD::mysql is
failing
to reset the Active attribute on the sth after fetching all the rows.
The
following test script shows this.

#!env perl

use strict;
use warnings;
use DBI;

my $dbh=DBI->connect(
'DBI:mysql:host=localhost;database=test',
'test' => '',
{ RaiseError => 1, PrintError => 1 }
);

my $sql = 'SELECT 1';

my $sth = $dbh->prepare_cached($sql);
print "Prepared active:",$sth->{Active},"\n";
$sth->execute;
print "Executed active:",$sth->{Active},"\n";
while ( $sth->fetchrow_hashref ) { }
print "Fetched active:",$sth->{Active},"\n";

# Prep again to see if we get Still Active warning
$sth = $dbh->prepare_cached($sql);

__END__

On a Debian System with
Linux jhary.itn.local 2.6.16-1-686 #1 Tue Mar 21 14:51:09 UTC 2006 i686
GNU/Linux
DBI 1.50
Perl v5.8.8 built for i486-linux-gnu-thread-multi
DBD::mysql 3.0006-1 or 3.0004-1

$ perl test-dbd-mysql.pl
Prepared active:
Executed active:1
Fetched active:1
prepare_cached(SELECT 1) statement handle DBI::st=HASH(0x82bb238) still
Active
at test-dbd-mysql.pl line 26

If I drop back to DBD::mysql 2.9006-1 it works again.

$ perl test-dbd-mysql.pl
Prepared active:
Executed active:1
Fetched active:

I can't test any other versions as the CPAN source won't complile on
this box
(Mysql deb doesn't seem to include mysql_config which the dbd make
wants)
and apt only offers me these versions.
Calling finish on the handle does reset the flag with any of the dbd
versions.
Playing with the mysql_server_prepare option doesn't seem to make any
difference.

Is anyone else seeing this? It seems odd that it didn't get spotted
through a
couple of release versions (although debian seem to be packaging the
developer
releases).

cheers,
mark
--






MARK ADDISON
WEB DEVELOPER

200 GRAYS INN ROAD
LONDON
WC1X 8XZ
UNITED KINGDOM
T +44 (0)20 7430 4678
F
E MARK.ADDISON@ITN.CO.UK
WWW.ITN.CO.UK
Please Note:



Any views or opinions are solely those of the author and do not necessarily represent
those of Independent Television News Limited unless specifically stated.
This email and any files attached are confidential and intended solely for the use of the individual
or entity to which they are addressed.
If you have received this email in error, please notify postmaster@itn.co.uk

Please note that to ensure regulatory compliance and for the protection of our clients and business,
we may monitor and read messages sent to and from our systems.

Thank You.

Re: DBD::mysql 3.0004+ not resetting $sth->{Active} after fetch

am 08.09.2006 17:56:59 von patg

Addison, Mark wrote:

Mark,

Stumbled upon your email from June, and am very sorry to not have seen
it and responded. I will have a fix for this within days with the
release of DBD::mysql 3.0007/3.0007_1

Kind regards,

Patrick

>Hello,
>
>I upgraded DBD::mysql from 2.9006-1 to 3.0006-1 and suddenly started
>getting
>screens full of errors like:
>
> prepare_cached(SELECT * FROM foo) statement handle
>DBIx::ContextualFetch::st=HASH(0x971cc80) still Active at
>/usr/share/perl5/Ima/DBI.pm line 381
>
>After some digging it seems that the new version of the DBD::mysql is
>failing
>to reset the Active attribute on the sth after fetching all the rows.
>The
>following test script shows this.
>
> #!env perl
>
> use strict;
> use warnings;
> use DBI;
>
> my $dbh=DBI->connect(
> 'DBI:mysql:host=localhost;database=test',
> 'test' => '',
> { RaiseError => 1, PrintError => 1 }
> );
>
> my $sql = 'SELECT 1';
>
> my $sth = $dbh->prepare_cached($sql);
> print "Prepared active:",$sth->{Active},"\n";
> $sth->execute;
> print "Executed active:",$sth->{Active},"\n";
> while ( $sth->fetchrow_hashref ) { }
> print "Fetched active:",$sth->{Active},"\n";
>
> # Prep again to see if we get Still Active warning
> $sth = $dbh->prepare_cached($sql);
>
> __END__
>
>On a Debian System with
> Linux jhary.itn.local 2.6.16-1-686 #1 Tue Mar 21 14:51:09 UTC 2006 i686
>GNU/Linux
> DBI 1.50
> Perl v5.8.8 built for i486-linux-gnu-thread-multi
> DBD::mysql 3.0006-1 or 3.0004-1
>
> $ perl test-dbd-mysql.pl
> Prepared active:
> Executed active:1
> Fetched active:1
> prepare_cached(SELECT 1) statement handle DBI::st=HASH(0x82bb238) still
>Active
> at test-dbd-mysql.pl line 26
>
>If I drop back to DBD::mysql 2.9006-1 it works again.
>
> $ perl test-dbd-mysql.pl
> Prepared active:
> Executed active:1
> Fetched active:
>
>I can't test any other versions as the CPAN source won't complile on
>this box
>(Mysql deb doesn't seem to include mysql_config which the dbd make
>wants)
>and apt only offers me these versions.
>Calling finish on the handle does reset the flag with any of the dbd
>versions.
>Playing with the mysql_server_prepare option doesn't seem to make any
>difference.
>
>Is anyone else seeing this? It seems odd that it didn't get spotted
>through a
>couple of release versions (although debian seem to be packaging the
>developer
>releases).
>
>cheers,
>mark
>--
>
>
>
>
>
>
>MARK ADDISON
>WEB DEVELOPER
>
>200 GRAYS INN ROAD
>LONDON
>WC1X 8XZ
>UNITED KINGDOM
>T +44 (0)20 7430 4678
>F
>E MARK.ADDISON@ITN.CO.UK
>WWW.ITN.CO.UK
>Please Note:
>
>
>
>Any views or opinions are solely those of the author and do not necessarily represent
>those of Independent Television News Limited unless specifically stated.
>This email and any files attached are confidential and intended solely for the use of the individual
>or entity to which they are addressed.
>If you have received this email in error, please notify postmaster@itn.co.uk
>
>Please note that to ensure regulatory compliance and for the protection of our clients and business,
>we may monitor and read messages sent to and from our systems.
>
>Thank You.
>
>

Re: DBD::mysql 3.0004+ not resetting $sth->{Active} after fetch

am 08.09.2006 18:38:45 von Mark.Addison

On Fri, 2006-09-08 at 11:56 -0400, Patrick Galbraith wrote:
> Addison, Mark wrote:
>
> Mark,
>
> Stumbled upon your email from June, and am very sorry to not have seen
> it and responded. I will have a fix for this within days with the
> release of DBD::mysql 3.0007/3.0007_1

Excellent, my logs will thankyou!
Radoslaw Pociecha has put a patch in the CPAN RT at
http://rt.cpan.org/Public/Bug/Display.html?id=20009

cheers,
mark


> >Hello,
> >
> >I upgraded DBD::mysql from 2.9006-1 to 3.0006-1 and suddenly started
> >getting
> >screens full of errors like:
> >
> > prepare_cached(SELECT * FROM foo) statement handle
> >DBIx::ContextualFetch::st=HASH(0x971cc80) still Active at
> >/usr/share/perl5/Ima/DBI.pm line 381
> >
> >After some digging it seems that the new version of the DBD::mysql is
> >failing
> >to reset the Active attribute on the sth after fetching all the rows.
> >The
> >following test script shows this.
> >
> > #!env perl
> >
> > use strict;
> > use warnings;
> > use DBI;
> >
> > my $dbh=DBI->connect(
> > 'DBI:mysql:host=localhost;database=test',
> > 'test' => '',
> > { RaiseError => 1, PrintError => 1 }
> > );
> >
> > my $sql = 'SELECT 1';
> >
> > my $sth = $dbh->prepare_cached($sql);
> > print "Prepared active:",$sth->{Active},"\n";
> > $sth->execute;
> > print "Executed active:",$sth->{Active},"\n";
> > while ( $sth->fetchrow_hashref ) { }
> > print "Fetched active:",$sth->{Active},"\n";
> >
> > # Prep again to see if we get Still Active warning
> > $sth = $dbh->prepare_cached($sql);
> >
> > __END__
> >
> >On a Debian System with
> > Linux jhary.itn.local 2.6.16-1-686 #1 Tue Mar 21 14:51:09 UTC 2006 i686
> >GNU/Linux
> > DBI 1.50
> > Perl v5.8.8 built for i486-linux-gnu-thread-multi
> > DBD::mysql 3.0006-1 or 3.0004-1
> >
> > $ perl test-dbd-mysql.pl
> > Prepared active:
> > Executed active:1
> > Fetched active:1
> > prepare_cached(SELECT 1) statement handle DBI::st=HASH(0x82bb238) still
> >Active
> > at test-dbd-mysql.pl line 26
> >
> >If I drop back to DBD::mysql 2.9006-1 it works again.
> >
> > $ perl test-dbd-mysql.pl
> > Prepared active:
> > Executed active:1
> > Fetched active:
> >
> >I can't test any other versions as the CPAN source won't complile on
> >this box
> >(Mysql deb doesn't seem to include mysql_config which the dbd make
> >wants)
> >and apt only offers me these versions.
> >Calling finish on the handle does reset the flag with any of the dbd
> >versions.
> >Playing with the mysql_server_prepare option doesn't seem to make any
> >difference.
> >
> >Is anyone else seeing this? It seems odd that it didn't get spotted
> >through a
> >couple of release versions (although debian seem to be packaging the
> >developer
> >releases).
> >
> >cheers,
> >mark
> >--
> >
> >
> >
> >
> >
> >
> >MARK ADDISON
> >WEB DEVELOPER
> >
> >200 GRAYS INN ROAD
> >LONDON
> >WC1X 8XZ
> >UNITED KINGDOM
> >T +44 (0)20 7430 4678
> >F
> >E MARK.ADDISON@ITN.CO.UK
> >WWW.ITN.CO.UK
> >Please Note:
> >
> >
> >
> >Any views or opinions are solely those of the author and do not necessarily represent
> >those of Independent Television News Limited unless specifically stated.
> >This email and any files attached are confidential and intended solely for the use of the individual
> >or entity to which they are addressed.
> >If you have received this email in error, please notify postmaster@itn.co.uk
> >
> >Please note that to ensure regulatory compliance and for the protection of our clients and business,
> >we may monitor and read messages sent to and from our systems.
> >
> >Thank You.
> >
> >
Please Note:



Any views or opinions are solely those of the author and do not necessarily represent
those of Independent Television News Limited unless specifically stated.
This email and any files attached are confidential and intended solely for the use of the individual
or entity to which they are addressed.
If you have received this email in error, please notify postmaster@itn.co.uk

Please note that to ensure regulatory compliance and for the protection of our clients and business,
we may monitor and read messages sent to and from our systems.

Thank You.