Edit report at https://bugs.php.net/bug.php?id=44454&edit=1
ID: 44454
Updated by: php-bugs@lists.php.net
Reported by: mfischer@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] uw@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] uw@php.net
No comment on the cause just some observations. Issue exists with SQLite as well.
[...]
------------------------------------------------------------------------
[2010-08-18 12:51:53] johannes@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