Re: selectrow_hashref() propagating wrong message (bug in DBD::mysql)

--00163630ed3dce26ff048d28ab17
Content-Type: text/plain; charset=ISO-8859-1

Hello All,

I have started to see random "fetch() without execute()" messages on a
production when mysql is under heavy load.  I believe the thread below
describes my problem (from dbi-dev mailing list circa 2007).  The production
system is currently using an older version of DBD::mysql and I wanted to
make sure this bug was fixed before scheduling an upgrade.  I looked through
changesets on github and couldn't pinpoint when it was fixed.  I tried to
compare the error handling between trunk and my version and couldn't see any
major difference (forgive me, it is my first time looking through dbd::mysql
source).  My question is was this fixed?  And if so, what was the fix?

Thanks,

Paul

===============

HTML version of the thread =>
http://www.nntp.perl.org/group/perl.dbi.dev/2007/03/msg4881.html

===============

From:
Patrick Galbraith
Date:
March 5, 2007 13:51
Subject:
Re: selectrow_hashref() propagating wrong message (bug in DBD::mysql)
Message ID:
[email protected]

Tim Bunce wrote:

Randy, Tim,

Thanks for the report and suggested fix. I'll fix this issue.

Kind regards,

Patrick

>On Fri, Mar 02, 2007 at 12:52:01PM -0800, Randy Harmon wrote:
>
>
>>Using DBI 1.53 as of this morning (also happened with 1.48).
>>
>>selectrow_hashref() was reporting "fetch() without execute()" when
>>$dbh->{PrintError} is true.  Since selectrow_hashref() is an opaque
>>function call, I'd expect it to report the actual error from the database.
>>
>>I suspected a database corruption problem, as this db server got hit
>>with an unexpected reboot.  But I wanted to be sure.   So I set
>>$dbh->{TraceLevel} = 2, and got the following output, indicating the
>>error message I suspected
>>
>>Is this an issue already known and slated for fix in an upcoming version?
>>
>>
>
>It's a bug in DBD::mysql:
>
>
>
>>-> selectrow_hashref for DBD::mysql::db (DBI::db=HASH(0x8d37b24)~0x8d28294
'select * from [...fnord...]'')
>>1   -> prepare for DBD::mysql::db (DBI::db=HASH(0x8d28294)~INNER 'select
>>* from [...fnord...]'' undef)
>>Setting mysql_use_result to 0
>>1   <- prepare= DBI::st=HASH(0x8de92f4) at DBI.pm line 1534
>>   -> execute for DBD::mysql::st (DBI::st=HASH(0x8de92f4)~0x8dd5018)
>>   -> dbd_st_execute for 08e0ccc0
>>Incorrect key file for table '[fnord]'; try to repair it error 1034
>>recorded: Incorrect key file for table '[fnord]'; try to repair it
>>   <- dbd_st_execute -1 rows
>>   !! ERROR: 1034 'Incorrect key file for table '[fnord]'; try to repair
it' (err#0)
>>   <- execute= -1 at DBI.pm line 1569
>>
>>
>
>The DBD::mysql execute method should return undef on error, not -1.
>
>Tim.
>
>


-- 
Patrick Galbraith, Senior Programmer
Grazr - Easy feed grazing and sharing
http://www.grazr.com

Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad

--00163630ed3dce26ff048d28ab17--