Bug #65945 [Opn->Nab]: Nested use of pdo->prepare()->execute clears the outer resultset-object

From: Date: Tue, 21 Oct 2014 17:56:34 +0000
Subject: Bug #65945 [Opn->Nab]: Nested use of pdo->prepare()->execute clears the outer resultset-object
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-188233@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=65945&edit=1 ID: 65945 Updated by: ssufficool@php.net Reported by: news at franky dot net Summary: Nested use of pdo->prepare()->execute clears the outer resultset-object -Status: Open +Status: Not a bug Type: Bug Package: PDO DBlib Operating System: Mac OS X 10.8.5 PHP Version: 5.4.21 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is the behavior of MSSQL (TDS), DBLIB and FreeTDS. One statement per connection rule. If you initiate another statement, the previous statement is cancelled. The previous versions buffered the entire result set in memory leading to OOM errors on large results sets. The previous behavior can be replicated using fetchAll() and a loop if desired. Another workaround is to open 2 connection objects, one per statement. Previous Comments: ------------------------------------------------------------------------ [2014-07-03 12:29:19] stasismedia at gmail dot com Same thing happening on Ubuntu 14.04, PHP 5.5.9-1ubuntu4.2 Here's a test script that doesn't require a table, if that helps: Test script: --------------- $dsn = 'dblib:dbname=DB_NAME;host=DB_HOST'; $db = new \PDO($dsn, 'USER', 'PASSWORD'); $statement = $db->prepare('SELECT 1 UNION SELECT 2 UNION SELECT 3'); $statement->execute(); while($row = $statement->fetch()) { $statement2 = $db->prepare('SELECT 1'); $statement2->execute(); $statement2->fetch(); // Loop will exit } ------------------------------------------------------------------------ [2014-06-30 20:21:24] deepdiver at owncloud dot com We at ownCloud are facing the same issue. Looks like the php 5.3 code base for pdo_dblib is fetch all rows within pdo_dblib_stmt_execute() - see https://github.com/php/php-src/blob/php-5.3.28/ext/pdo_dblib/dblib_stmt.c#L145 Might that be related to this comment in the freedts docs: http://www.freetds.org/userguide/samplecode.htm (search for 'Fetch All Rows!') Any further guidance is welcome - we are happy to 'donate' developer time to this issue - if this helps ;-) ------------------------------------------------------------------------ [2013-12-30 13:41:16] cweiske@php.net This also happens with "normal" queries executed via $pdo->query('..'), not only with prepared statements. ------------------------------------------------------------------------ [2013-10-22 13:46:52] news at franky dot net Description: ------------ In PHP 5.3 the test script works fine and gives me the results as you see in "expected result". If i use PHP 5.4 or PHP 5.5, the inner pdo->prepare()->execute clears the outer PDO-Resultset unexpectedly. Test script: --------------- $pdo = new PDO("dblib:host=192.168.1.100;dbname=kunden;charset=UTF-8;", "kunden", "geheim"); $stmt = $pdo->prepare("select top 10 * from Kunden"); $stmt->execute(); while($row = $stmt->fetch()) { echo 'KundenID: ' . $row["KundenID"] . '<br />'; $stmt2 = $pdo->prepare("select top 10 * from Ansprechpartner where KundenID=?"); $stmt2->execute(array($row["KundenID"])); while($row2 = $stmt2->fetch()) { echo 'AnsprechpartnerID: ' . $row2["AnsprechpartnerID"] . '<br />'; } } unset($pdo); Expected result: ---------------- KundenID: 10 AnsprechpartnerID: 1624 AnsprechpartnerID: 1716 AnsprechpartnerID: 7823 AnsprechpartnerID: 9309 AnsprechpartnerID: 10398 AnsprechpartnerID: 18686 KundenID: 13 AnsprechpartnerID: 1621 KundenID: 15 AnsprechpartnerID: 1596 AnsprechpartnerID: 4769 AnsprechpartnerID: 92891 Actual result: -------------- KundenID: 10 AnsprechpartnerID: 1624 AnsprechpartnerID: 1716 AnsprechpartnerID: 7823 AnsprechpartnerID: 9309 AnsprechpartnerID: 10398 AnsprechpartnerID: 18686 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=65945&edit=1

« previous php.bugs (#188233) next »