Edit report at https://bugs.php.net/bug.php?id=44454&edit=1
ID: 44454 Updated by: php-bugs@lists.php.net Reported by: mfisc...@php.net Summary: Unexpected exception thrown in foreach() statement -Status: Feedback +Status: No Feedback Type: Bug Package: PDO related Operating System: * PHP Version: 5.*, 6CVS (2009-04-25) New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: ------------------------------------------------------------------------ [2011-01-04 17:22:20] rgagnon24 at gmail dot com Problem still exists in PHP 5.3 snapshot 201101041530 Patch uploaded to account for the changes in mysql_statement.c since the last time I patched PHP 5.2 ------------------------------------------------------------------------ [2011-01-04 13:37:07] u...@php.net Not a MySQL specific issue thus it should not be assigned to mysql, see my earlier comment: [2008-07-03 14:37 UTC] u...@php.net No comment on the cause just some observations. Issue exists with SQLite as well. [...] ------------------------------------------------------------------------ [2010-08-18 12:51:53] johan...@php.net Please try a 5.3 snapshot. ------------------------------------------------------------------------ [2010-06-03 20:58:10] rgagnon24 at gmail dot com I've attached a patch "fix-mysql_statement.c-5.2.13.patch" to resolve this problem. From: http://dev.mysql.com/doc/refman/5.0/en/mysql-fetch-row.html "When used after mysql_store_result(), mysql_fetch_row() returns NULL when there are no more rows to retrieve. When used after mysql_use_result(), mysql_fetch_row() returns NULL when there are no more rows to retrieve or if an error occurred" The patch simply does not raise an exception during a NULL result from mysql_fetch_row() since it only indicates the exhaustion of data. The condition added simply matches the use of either mysql_use_result() or mysql_store_result() called in pdo_mysql_stmt_execute(). When not buffered, mysql_use_result() is called. Therefore, the same check is performed after the fetch before deciding to raise an exception. Also, when un-buffered queries are used, the test script above would be invalid as you cannot perform another operation on a result-set when not all of the results have been retrieved. The patch was created against the released PHP 5.2.3 source code tarball. It's so small, you should be able to modify it easily for any version of the mysql_statement.c file. ------------------------------------------------------------------------ [2010-06-03 20:36:48] rgagnon24 at gmail dot com From: http://dev.mysql.com/doc/refman/5.0/en/mysql-errno.html "Note that some functions like mysql_fetch_row() don't set mysql_errno() if they succeed." And: http://dev.mysql.com/doc/refman/5.0/en/mysql-fetch-row.html "Note that error is not reset between calls to mysql_fetch_row()" ----------------------------------------------------------------------------- Since all the SELECT'd rows are fetched ok, the error from the botched insert is still hanging around for mysql_errno() to find, and raise the exact same exception after the data is finished being iterated. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=44454 -- Edit this bug report at https://bugs.php.net/bug.php?id=44454&edit=1
