php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #55536 MySQLi fetch corrupting bound variables
Submitted: 2011-08-30 10:31 UTC Modified: 2011-09-02 13:36 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:2 (66.7%)
From: taopixdev at yahoo dot co dot uk Assigned:
Status: Not a bug Package: MySQLi related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: taopixdev at yahoo dot co dot uk
New email:
PHP Version: OS:

 

 [2011-08-30 10:31 UTC] 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-09-02 11:45 UTC] uw@php.net
-Status: Open +Status: Bogus
 [2011-09-02 11:45 UTC] uw@php.net 
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-09-02 13:36 UTC] taopixdev at yahoo dot co dot uk 
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 14:01:32 2024 UTC