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.

Also tested on Ubuntu 12.04 with PHP 5.4.15 and it does not work

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. :(

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.

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.

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"
  }
}

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))

See commit 9ef762d:
[master 9ef762d] FIX BUG #64522
 1 file changed, 2 insertions(+), 3 deletions(-)

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.

+1 Whats release for this?

Version 5.4.15 was already working properly. I which version/OS have you seen this bug?