ID: 26407 Updated by: [EMAIL PROTECTED] Reported By: tvoigt at informatik dot tu-cottbus dot de Status: Open Bug Type: Sybase-ct (ctlib) related Operating System: Linux (i686) & Solaris 8 PHP Version: 4.3.4 New Comment:
Can neither reproduce with PHP/4.3.4 nor with current CVS. I'm using FreeTSD v.0.62 under FreeBSD/4.8-STABLE. Maybe this occurs with the Sybase-libraries only? Could you provide the ouput of $ make test TESTS=ext/sybase_ct/ (execute in top source directory of a PHP checkout / snap) Previous Comments: ------------------------------------------------------------------------ [2003-12-02 10:25:11] tvoigt at informatik dot tu-cottbus dot de All sample queries above execute perfectly well up to PHP version 4.3.3; on PHP-4.3.4 (and later devel snapshots) I'll get the OpenClient error message and those queries don't work. Both PHP versions are configured identically (on both machines, running Solaris or Linux). Nothing else has been altered. So whatever upsets OpenClient must have its origin in changed code in PHP-4.3.4... Thanks and best regards, Thomas ------------------------------------------------------------------------ [2003-12-01 11:57:39] [EMAIL PROTECTED] The other changes in the sources can not cause this. Are you sure this isn't openclient bug? Maybe you should ask them.. ------------------------------------------------------------------------ [2003-12-01 11:50:48] tvoigt at informatik dot tu-cottbus dot de Hi there! Thanks for your reply! Don't know if the mentioned bug/patch #23682 really interferes with my problem. The patch mainly skips unwanted (pseudo-)results in favor for getting the first real result set, right? Whereas I'm not *that* interested in fetching a particular result. But I have to depend on the database executing all of my queries up to the end. Because of query (II.) above, I assume that something deeper inside the query executing/fetching mechanism is broken: Query (II.) doesn't produce multiple result sets at all -- and the query fails with an OpenClient message. I'm not very familiar with C, but a 'diff' shows many changes in php_sybase_ct.c (4.3.3 -> 4.3.4) besides that patch from #23682: A lot of pointers became pointers of pointers and some additional Zend stuff moved in. The reported error message comes from the OpenClient library. Skipping some unwanted results should not bother the underlying database library, could it? Maybe there are some changes made in communication timing and/or execution order? Sybase's OpenClient documentation sadly is not very explicit about error #155, but some quite similar errors origin in wrong timing or execution order. Thanks again for your time! Best regards, Thomas ------------------------------------------------------------------------ [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
