Bug #64522 [Com]: After first query to MSSQL (DBLIB) all the other queries return null values

Edit report at https://bugs.php.net/bug.php?id=64522&edit=1 ID: 64522 Comment by: capile at tecnodz dot com 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: 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" } } Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2013-03-26 18:44:16] 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. ------------------------------------------------------------------------ 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