Edit report at https://bugs.php.net/bug.php?id=64522&edit=1
ID: 64522
Updated by: ssufficool@php.net
Reported by: capile at tecnodz dot com
Summary: After first query to MSSQL (DBLIB) all the other
queries return null values
Status: Open
Type: Bug
Package: PDO related
Operating System: Ubuntu Linux
PHP Version: 5.4.13
Block user comment: N
Private report: N
New Comment:
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))
Previous Comments:
------------------------------------------------------------------------
[2013-05-29 13:51:34] 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-29 12:48:38] 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 03:42:49] 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 02:38:18] 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-28 17:19:11] mneyman at yesco dot com
Also tested on Ubuntu 12.04 with PHP 5.4.15 and it does not work
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=64522--
Edit this bug report at https://bugs.php.net/bug.php?id=64522&edit=1