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.