From: tvoigt at informatik dot tu-cottbus dot de Operating system: Linux (i686) & Solaris 8 PHP version: 4.3.4 PHP Bug Type: Sybase-ct (ctlib) related Bug description: Result set fetching broken around transactions (OpenClient Error #155)
Description: ------------ Hi there! When executing queries including a transaction and returning some result set PHP won't get any result handle, but the following OpenCLient error message (#155): "ct_results(): user api layer: external error: This routine cannot be called when the command structure is idle." Or in German: "ct_results(): Benutzer-API-Schicht: Externer Fehler: Aufruf der Routine nicht möglich, wenn die Befehlsstruktur nicht aktiv ist." My PHP-script continues to run (no crashes whatsoever), but the query has not been perfectly executed by Sybase. The error is reproducible with PHP-4.3.4 on quite different machines, a Sun UltraSparc running SunOS 5.8 and a i686 Linux box (Debian Woody 3.0R1). Even tried PHP-4.3.5-dev (php4-STABLE-200311251230) and got the same error. Database is Sybase 11.9.2. Each query executes flawlessly via the isql frontend -- and did so up to PHP-4.3.3 (on the same machines, configured identically). PHP configuration (Linux box): ./configure \ --with-regex=system \ --with-apxs=/usr/local/apache/bin/apxs \ --without-pear \ --with-openssl \ --with-zlib \ --enable-calendar \ --with-pfdlib=/usr/local/lib \ --with-pgsql \ --with-mysql=/usr/ \ --with-sybase-ct=/opt/sybase-11.9.2 \ --with-oci8=/usr/local/oracle \ --with-oracle=/usr/local/oracle \ --with-gd=/usr/local \ --enable-gd-native-ttf \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/lib \ --with-ttf=/usr/local/lib \ --with-freetype-dir=/usr/local/lib \ --enable-exif \ --enable-sigchild \ --enable-track-vars PHP configuration (Sun machine): ./configure --with-apxs=/usr/local/apache-1.3.28/bin/apxs --disable-shared --enable-static --with-openssl=/usr/local/ssl --with-sybase-ct=/usr/local/Sybase --with-mysql=/usr/local/mySQL --with-pgsql=/usr/local/PostgreSQL --with-db4=/usr/local/BerkeleyDB-4.1 --with-gd=/usr/local --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-xpm-dir=/usr/local --with-freetype-dir=/usr/local --with-zlib=/usr/local --with-ftp --with-xml --enable-track-vars Reproduce code: --------------- /* I. fails: */ begin transaction -- anything producing a result set here will fail; -- however, print or update statements will work select "foo" commit -- anything afterwards will fail, too /* II. fails: */ begin transaction -- no result returned... update foobar set the_big_answer=42 commit -- transaction is completed (correctly, indeed)... select "foo" -- ...but select statement afterwards fails, nonetheless /* III. works as expected: */ select "foo" begin transaction -- do anything, even return a result set commit select "bar" -- or even do something useful like updates... Expected result: ---------------- Sorry for all that SQL up there, but I've spend most of a day tracking my problem down and figuring out some hopefully useful examples. Yes, I know that Sybase queries returning multiple result sets are not completely fetchable by PHP (at most, one will get the first result set back). But I expect the whole query to be executed. In fact, I'm calling a set of stored procedures doing some quite important stuff, not just worshiping RFC 3092 ;-) Actual result: -------------- Queries invoking statements that return fetchable result sets (via select, stored procedures) inside (I.) or AFTER a transaction block (II.) will fail. However, the first part of query II (the entire transaction block) is executed correctly, but PHP won't see no result handle. Other statements like print or update inside transactions work fine. I assume there is a bug (introduced with PHP-4.3.4) fetching the result set inside and around transactions, because similar queries with a fetchable result *before* a transaction block work as expected up to the end (III). As said before, all these queries work perfectly well up to PHP-4.3.3; simple workaround for me would be to insert some (fetchable) dummy selects on top of each transaction. But that's not the point of a bug report, is it? I very appreciate your help and all the work you do! Best regards and thanks in advance, Thomas Voigt -- Edit bug report at http://bugs.php.net/?id=26407&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26407&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26407&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26407&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26407&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26407&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26407&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=26407&r=support Expected behavior: http://bugs.php.net/fix.php?id=26407&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=26407&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=26407&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26407&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26407&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26407&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26407&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=26407&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26407&r=float
