On 6/11/07, Brandon Black <[EMAIL PROTECTED]> wrote:
Are you sure $@ is being set? If $sth->execute() is returning a false value that would trip up the current code as well (as it checks !$rv). DBI says false return values are an error for $sth->execute (zero rows is "0E0", which is zero but true), but perhaps MySQL + DBD::mysql return an actual zero in your case? Come to think of it, since we now enforce RaiseError (and doc that coderef connect users should be setting it, it's arguable we shouldn't be checking the retval for errors at all. You might look at what $rv is near that line 883, and/or try removing the !$rv check.
$@ is set and $rv is false but no real error occurred. The issue seems to happen because when the failing $sth->execute() is called, another two calls to _dbh_execute() are issued before the first $sth->execute() returns. I couldn't really understand why it happens that way, but those "nested" calls seemed to be somewhat related to DBIx::Class::Storage::DBI::Cursor since it was being passed as one of the parameters. -Nilson Santos F. Jr. _______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/ Searchable Archive: http://www.mail-archive.com/[email protected]/
