php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #70786 mysqli_stmt objects can not be processed in the nested iterations
Submitted: 2015-10-25 20:08 UTC Modified: 2015-10-26 12:30 UTC
From: it_poz at interia dot eu Assigned:
Status: Open Package: MySQLi related
PHP Version: irrelevant OS: irrelevant
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2015-10-25 20:08 UTC] it_poz at interia dot eu
Description:
------------
The environment:
MS Win Vista Business 64-bit, MySQL 5.6.26, PHP 7.0RC5 on IIS 7.0 via FastCGI, mysqli ext installed.


The mysqli_stmt objects can not be processed in the nested iterations – looks like, they influence to each other.

Probably the second mysqli_stmt object (see the example script) doesn’t work at all due to some collision to the first one.
Same problem I have observed in the earlier PHP versions like PHP 5.6.14, 5.5.30, 5.4.45 and 5.3.29.

In the example I have used the SELECT query, but even more strange behavior have been noticed for the other statement queries like UPDATE or INSERT and it is very difficult find the reason of that (see the debug info in the example code).



Similar task, but realized within the MySQL client (5.6.26 for MS Windows) works well and as expected. It is possible to PREPARE and EXECUTE prepared statements in any order and the defined statements can coexist and don’t influence to each other.

Test script:
---------------
Let’s consider very simple example of two tables in the data base (MySQL):

tbl_1
---------------------------
| id_tbl_1 |  name_tbl_1  |
---------------------------
|      1   |     ntbl1_1  |
|      2   |     ntbl1_2  |
---------------------------

tbl_2
---------------------------
| id_tbl_2 |  name_tbl_2  |
---------------------------
|      1   |     ntbl2_1  |
|      2   |     ntbl2_2  |
---------------------------

It doesn’t matter whether the tables are somehow related or not.


The PHP code:

// the MySQL connection is established and is correct for the right user with adequate privileges – the connection handler is $db_res

$stmt_1 = $db_res->stmt_init();
$stmt_1->prepare('SELECT name_tbl_1 FROM tbl_1 WHERE id_tbl_1 = ?');
$stmt_2 = $db_res->stmt_init();
$stmt_2->prepare('SELECT name_tbl_2 FROM tbl_2 WHERE id_tbl_2 = ?');

for ($i = 1; $i <= 2; $i++) {
  $stmt_1->bind_param('i', $i);      // returns TRUE here
  $stmt_1->execute();                // returns TRUE here
  $stmt_1->bind_result($name_1);     // returns TRUE here
  $stmt_1->fetch();                  // returns TRUE here
  echo $name_1.'<br />';
  for ($j = 1; $j <= 2; $j++) {
    $stmt_2->bind_param('i', $j);    // returns TRUE here
    $stmt_2->execute();              // returns TRUE here
    $stmt_2->bind_result($name_2);   // returns TRUE here
    $stmt_2->fetch();                // returns FALSE here
    echo '------'.$name_2.'<br />';
  }
}
$stmt_1->close();
$stmt_2->close();

// close data base connection

Expected result:
----------------
The expected result should be something like that:

ntbl1_1
------ntbl2_1
------ntbl2_2
ntbl1_2
------ntbl2_1
------ntbl2_2

Actual result:
--------------
but the received result, unfortunately is like that:

ntbl1_1
------
------
ntbl1_2
------
------

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-10-26 12:30 UTC] it_poz at interia dot eu
-Operating System: MS Windows Vista Business 64-bit +Operating System: irrelevant -PHP Version: 7.0.0RC5 +PHP Version: irrelevant
 [2015-10-26 12:30 UTC] it_poz at interia dot eu
Checked on Linux Fedora 22 and PHP 5.6.14 - the same problem occures, so the bug is OS and PHP version irrelevant.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sun Apr 05 10:01:27 2020 UTC