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.