ID: 39618 User updated by: randy at rcs-comp dot com Reported By: randy at rcs-comp dot com Status: Open -Bug Type: Documentation problem +Bug Type: PDO related Operating System: Windows XP PHP Version: 5.2.0 New Comment:
THIS IS NOT A DOCUMENTATION PROBLEM!!! The documentation describes the best way for the function to work. It is a problem with a PDO driver not working like every other PDO driver! What is the point of a database abstraction layer if you can't rely upon it to be consistent across drivers!!!! If you insist that this is a documentation problem, will you please have another PHP developer chime in and agree with you. If so, I will leave the bug report alone. Thank you. Previous Comments: ------------------------------------------------------------------------ [2006-11-28 14:22:46] [EMAIL PROTECTED] Reclassified as docu problem. ------------------------------------------------------------------------ [2006-11-28 14:20:00] randy at rcs-comp dot com Tony, Thank you for your time on this and the explanation. However, I still think this represents a bug in PHP for three reasons. 1) The documentation says "PDOStatement::rowCount -- Returns the number of rows affected by the last SQL statement" Notice that it says "the last" SQL statement. In my example, the rowCount() returns the SUM of several SQL statements not the total of the "last SQL statement." This function does not work the way the documentation says it does, and is therefore buggy. 2) I understand what you are saying about "this is how it is supposed to work in Sqlite2." However, just because SQLite2 is working correctly does not automatically mean that PDO is working correctly. PDO is a database abstraction layer whose purpose is to hide the implimenation details of the specific drivers for PHP developers. If you don't fix this bug, every SQLite2 developer would need to be aware of this driver specific issue and code around it. 3) I tested PDO MySQL, PDO Mssql, and PDO SQLite 3 and NONE of them exhibit the behavior of PDO SQLite2. This is a huge incompatability for the SQLite 2 driver. I welcome a difference of opinion, but honestly it seems pretty clear to me that this is a bug. ------------------------------------------------------------------------ [2006-11-28 11:07:12] [EMAIL PROTECTED] See http://www.sqlite.org/cvstrac/tktview?tn=383 "The sqlite_changes API function returns the number of rows that have been inserted, deleted, or modified since the database was last quiescent. A "quiescent" database is one in which there are no outstanding calls to sqlite_exec and no VMs created by sqlite_compile that have not been finalized by sqlite_finalize." This is how it is supposed to work in Sqlite2, but Sqlite3 seems to work differently. ------------------------------------------------------------------------ [2006-11-24 14:56:53] randy at rcs-comp dot com Description: ------------ After using prepare() & execute() to retrieve a PDO Statement from a PDO Sqlite2 connection, subsequent calls to exec() return a "rows affected" value that appears to sum the previous calls to exec() together. Reproduce code: --------------- http://www.rcs-comp.com/phpcode/simple_pdo_test3.php.txt Expected result: ---------------- >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 rows updated w/ exec() (some): 2 2 rows updated w/ prep & execute() (all): 3 3 Actual result: -------------- >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 5 <-- notice the addition from the prev. row rows updated w/ exec() (some): 2 7 <-- notice the addition from the prev. row rows updated w/ prep & execute() (all): 3 3 <-- problem disappears ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=39618&edit=1
