php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #64522 After first query to MSSQL (DBLIB) all the other queries return null values
Submitted: 2013-03-26 18:24 UTC Modified: 2014-03-12 13:32 UTC
Votes:4
Avg. Score:4.0 ± 0.7
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:2 (66.7%)
From: capile at tecnodz dot com Assigned: ssufficool (profile)
Status: Closed Package: PDO related
PHP Version: 5.4.13 OS: Ubuntu Linux
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: capile at tecnodz dot com
New email:
PHP Version: OS:

 

 [2013-03-26 18:24 UTC] capile at tecnodz dot com
Description:
------------
After first statement/query/exec (successful or not) all the other statements return null as a result. There's nothing relevant in the PDOStatement::errorInfo().

Occurs no matter if the statement cursor was closed or not.

Tested on:
* Ubuntu 12.10 with both PHP 5.4.6 and 5.4.13 (doesn't work)
* Ubuntu 13.04 with PHP 5.4.9 (doesn't work)
* Ubuntu 12.04 with PHP 5.3.10 (works)

All the installations were made with apt-get (PHP 5.4.13 from http://ppa.launchpad.net/ondrej/php5/ubuntu).

All of them use the PDO version 1.0.4dev (got with `php --re pdo`)

Test script:
---------------
$pdo=new PDO('dblib:host=db;dbname=admin;charset=UTF-8',$username,$password);

$statement=$pdo->query('select 1+1 as result');
print_r($statement->fetchAll());
$statement->closeCursor();

$statement=$pdo->query('select 1+1 as result');
print_r($statement->fetchAll());



Expected result:
----------------
Array
(
    [0] => Array
        (
            [result] => 2
            [0] => 2
        )

)
Array
(
    [0] => Array
        (
            [result] => 2
            [0] => 2
        )

)

Actual result:
--------------
Array
(
    [0] => Array
        (
            [result] => 2
            [0] => 2
        )

)
Array
(
)

Patches

FIX_BUG_64522 (last revision 2013-05-31 04:47 UTC by ssufficool@php.net)

Add a Patch

Pull Requests

Pull requests:

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-03-26 18:44 UTC] capile at tecnodz dot com
Downgraded PHP on Ubuntu 12.10 to 5.3.10 and now it works. I also noticed that cursors are closed at each statement/query/exec.
 [2013-05-28 17:19 UTC] mneyman at yesco dot com
Also tested on Ubuntu 12.04 with PHP 5.4.15 and it does not work
 [2013-05-29 02:38 UTC] ssufficool@php.net
The issue may be the way the cursor closer is implemented. It frees the column 
metadata but I can't find where it is reallocated for the next statement. This 
may be allocated in PDO core. I remember writing tests, but they did not call 
"$stmt->closeCursor();". Does your script work without the closeCursor()?

I have no way to test anymore since I do not have an SQL/Sybase server to 
connect to. :(
 [2013-05-29 03:42 UTC] ssufficool@php.net
I installed Sybase Adaptive Server and was able to reproduce. A workaround is to 
do a $statement=null and then reuse the $statement variable. This calls the 
statement destructor in addition to the cursorCloser(). 

This may be something new to the PDO core. From what I can see on git, no changes 
have been made to pdo_dblib since it was last working. I will continue to look 
into this.
 [2013-05-29 12:48 UTC] capile at tecnodz dot com
using $statement = null; would make it impossible to use transactions and some stored procedures.

This was introduced back in late 2011(https://github.com/php/php-src/commit/3a069e814fe01b36812b5c768dd52ccdea3ed098) but only on PHP 5.4+ (5.3- worked as expected).

I compiled PHP 5.4.13 with the pull request applied and it worked as expected.
 [2013-05-29 13:51 UTC] capile at tecnodz dot com
Sorry, I commented without properly testing, just compiled 5.4.15 and tested with $statement = null; and it was possible to keep using the connection, even with transactions.

Also works with unset($statement);

Test script:
---------------
$db->exec('create table #test ( id int not null )');
$db->exec('begin transaction test1');
$db->exec('insert into #test (id) values (100)');
$db->exec('insert into #test (id) values (200)');
$db->exec('insert into #test (id) values (300)');
$db->exec('commit transaction test1');
$stmt = $db->query('select * from #test');
var_dump($stmt->fetchAll(PDO::FETCH_NUM));
$stmt->closeCursor();
unset($stmt);
$db->exec('drop table #test');


Expected result:
----------------
array(3) {
  [0]=>
  array(1) {
    [0]=>
    string(3) "100"
  }
  [1]=>
  array(1) {
    [0]=>
    string(3) "200"
  }
  [2]=>
  array(1) {
    [0]=>
    string(3) "300"
  }
}
 [2013-05-30 05:12 UTC] ssufficool@php.net
The pull request attached to this bug report will introduce another error when 
the another statement is issued without fetching ALL the previous results:

SQLSTATE[HY000]: General error: 20019 Attempt to initiate a new Adaptive Server 
operation with results pending [20019] (severity 7) [select 1+1 as result1]

The last statement should be able to be flushed using dbcancel(), but for some 
reason this is not working as documented. I also tried dbcanquery(). Both render 
the statement not re-useable, but weirdly enough the column metatdata is 
repopulated with the new column names and types

code: print_r($pdo->getColumnMeta(0))
 [2013-05-31 04:35 UTC] ssufficool@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: ssufficool
 [2013-05-31 04:35 UTC] ssufficool@php.net
See commit 9ef762d:
[master 9ef762d] FIX BUG #64522
 1 file changed, 2 insertions(+), 3 deletions(-)
 [2013-05-31 04:47 UTC] ssufficool@php.net
The following patch has been added/updated:

Patch Name: FIX_BUG_64522
Revision:   1369975647
URL:        https://bugs.php.net/patch-display.php?bug=64522&patch=FIX_BUG_64522&revision=1369975647
 [2013-05-31 04:59 UTC] ssufficool@php.net
Automatic comment on behalf of ssufficool
Revision: http://git.php.net/?p=php-src.git;a=commit;h=0074cd2675687a25155cdde2ebc6b9f4a709c743
Log: pdo_dblib: fix bug #64522DBLIB statement destructor was being called late and clobbered results from subsequent statement objects sharing the same connection
 [2013-05-31 05:00 UTC] ssufficool@php.net
-Status: Assigned +Status: Closed
 [2013-05-31 05:00 UTC] ssufficool@php.net
The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.


 [2013-11-17 09:31 UTC] laruence@php.net
Automatic comment on behalf of ssufficool
Revision: http://git.php.net/?p=php-src.git;a=commit;h=0074cd2675687a25155cdde2ebc6b9f4a709c743
Log: pdo_dblib: fix bug #64522DBLIB statement destructor was being called late and clobbered results from subsequent statement objects sharing the same connection
 [2014-03-11 19:31 UTC] fabio dot ginzel at pandora dot com dot br
+1 Whats release for this?
 [2014-03-12 13:32 UTC] capile at tecnodz dot com
Version 5.4.15 was already working properly. I which version/OS have you seen this bug?
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sun Oct 17 07:03:33 2021 UTC