Bug #55536 [Bgs]: MySQLi fetch corrupting bound variables
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] 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-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
Thread (3 messages)