Edit report at https://bugs.php.net/bug.php?id=55536&edit=1
ID: 55536 User updated by: taopixdev at yahoo dot co dot uk Reported by: taopixdev at yahoo dot co dot uk Summary: MySQLi fetch corrupting bound variables Status: Bogus Type: Bug Package: MySQLi related PHP Version: Irrelevant Block user comment: N Private report: N New Comment: Sorry, I don't agree - it is not okay and definitely not bogus. The documentation for mysqli_stmt::bind_result states: "Binds columns in the result set to variables." If there are no records to fetch then there is nothing to set - ie: nothing to change. Nowhere does it say that the values are set to null. The functionality in 5.2 (and probably before) is correct so why break it in 5.3? I also do not agree with your statement: "It is secondary if there is a result set or not. What's relevant in the above is the fact that bound columns are set." What benefit does setting the values to null give? You can already detect if there are no more records by the result of the fetch command. The outcome of this is that we have to re-write and Q.A. code for no good reason. What is also extremely annoying is that this change was not documented which to me seems as if it is an accidental change to functionality (ie: a bug). We have also found one machine in our office running PHP 5.3 that works the same way as 5.2 so the functionality is not even consistent. Previous Comments: ------------------------------------------------------------------------ [2011-09-02 11:45:44] [email protected] I think the current behavior - setting bound result variables to NULL - OK . Bound columns are explicitly mentioned as being modified when running a prepared statement: "Binds columns in the result set to variables. When mysqli_stmt_fetch() is called to fetch data, the MySQL client/server protocol places the data for the bound columns into the specified variables var1, .... ", http://de2.php.net/manual/en/mysqli-stmt.bind-result.php It is secondary if there is a result set or not. What's relevant in the above is the fact that bound columns are set. Setting to NULL in case of no result set makes perfectly sense. It means "setting" (as documented) and setting to "undefined" (because of no result set). ------------------------------------------------------------------------ [2011-08-30 10:31:05] taopixdev at yahoo dot co dot uk Description: ------------ I have tested this in different versions of PHP and it seems to be a bug from version 5.3.0 onwards. It seems that from PHP version 5.3.0 onwards that when a MySQL select statement returns zero rows the bind result variable is being overwritten and set to a null value. In the example attached to this post I initialize a variable called $recordID and set it to 0; In versions of PHP prior to version 5.3.0 after the fetch has ran the $recordID would still be set to 0 when zero rows are returned. However from versions 5.3.0 onwards the $recordID variable is overwritten and set to null. Test script: --------------- <?php $pID = 0; $recordID = 0; if ($stmt = $dbObj->prepare('SELECT `id`, `name` FROM MYTABLE WHERE id = ?) { if ($stmt->bind_param('i', $pID)) { if ($stmt->bind_result($recordID, $name) { if ($stmt->execute()) { $stmt->fetch(); } } } } ?> Expected result: ---------------- In versions of PHP prior to version 5.3.0 after the fetch has ran the $recordID would still be set to 0 when zero rows are returned. Actual result: -------------- >From versions 5.3.0 onwards the $recordID variable is overwritten and set to >null. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=55536&edit=1
