ID: 26407 Updated by: [EMAIL PROTECTED] Reported By: tvoigt at informatik dot tu-cottbus dot de -Status: Feedback +Status: No Feedback Bug Type: Sybase-ct (ctlib) related Operating System: Linux (i686) & Solaris 8 PHP Version: 4.3.4 New Comment:
No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: ------------------------------------------------------------------------ [2003-11-25 14:47:32] [EMAIL PROTECTED] I would guess this is caused by fixing other bug: http://bugs.php.net/bug.php?id=23682 Check that out.. ------------------------------------------------------------------------ [2003-11-25 10:40:09] tvoigt at informatik dot tu-cottbus dot de 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 this bug report at http://bugs.php.net/?id=26407&edit=1
