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
