php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60930 PDO exec
Submitted: 2012-01-30 01:26 UTC Modified: 2012-05-02 09:53 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: lenzai2004-dev at yahoo dot fr Assigned:
Status: Not a bug Package: PDO related
PHP Version: 5.3.9 OS: Ubuntu 11.10 64bits
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: lenzai2004-dev at yahoo dot fr
New email:
PHP Version: OS:

 

 [2012-01-30 01:26 UTC] lenzai2004-dev at yahoo dot fr
Description:
------------
 SQL statement that return or should return a statement could leave an open cursor that cannot be closed.


This bug is related to the following previous reports

https://bugs.php.net/bug.php?id=36347
https://bugs.php.net/bug.php?id=34499
https://bugs.php.net/bug.php?id=42499

It's been reported that sql statement that do return result could cause this issue in non trivial situations.
This report also highlight that statement returning empty result set could also cause the issue.

Test script:
---------------
$dbh = new PDO("mysql:your connection string", '', '');

echo $dbh->exec("SELECT * FROM cube where false");
echo $dbh->exec("SELECT * FROM cube where false");
print_r($dbh->errorInfo());

Expected result:
----------------
00

Actual result:
--------------
0Array
(
    [0] => HY000
    [1] => 2014
    [2] => Cannot execute queries while other unbuffered queries are active.  Consider using PDOStatement::fetchAll().  
Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::
MYSQL_ATTR_USE_BUFFERED_QUERY attribute.
)


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-05-02 09:27 UTC] uw@php.net
There is no bug here. Do as the message says and everything works fine.

It is not possible to run another statement on a MySQL line prior to fetching the results. By default - as the message says - there is no implicit fetch of results. Thus, you must explicitly fetch them.
 [2012-05-02 09:27 UTC] uw@php.net
-Status: Open +Status: Not a bug
 [2012-05-02 09:53 UTC] lenzai2004-dev at yahoo dot fr
You are right , this more of API design/enhancement request.

the current behaivour is very hard to debug because the second statement raise an error caused by the first one.

it does not tell what was the SQL statement or ID
it does not tell which line in php source code  created thsi statement.

If the 2 statements are in unrelated location in source code it makes this situation almost impossible to debug. Even worse if the SQL statement was generated dynamically or comes external input.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 23 15:01:32 2024 UTC