php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #26407 Result set fetching broken around transactions (OpenClient Error #155)
Submitted: 2003-11-25 10:40 UTC Modified: 2004-02-15 05:50 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: tvoigt at informatik dot tu-cottbus dot de Assigned:
Status: Closed Package: Sybase-ct (ctlib) related
PHP Version: 4CVS, 5CVS OS: Linux (i686) & Solaris 8
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
35 + 5 = ?
Subscribe to this entry?

 
 [2003-11-25 10:40 UTC] 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

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-11-25 14:47 UTC] sniper@php.net
I would guess this is caused by fixing other bug:

http://bugs.php.net/bug.php?id=23682

Check that out..

 [2003-12-01 11:50 UTC] 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-12-01 11:57 UTC] sniper@php.net
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-02 10:25 UTC] 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
 [2004-01-23 21:52 UTC] thekid@php.net
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)
 [2004-01-26 07:20 UTC] tvoigt at informatik dot tu-cottbus dot de
Yes, we have Sybase's ctlib in production. We decided against FreeTDS here (for it crashed *way* too often).

Here is the test output created by PHP/4.3.5RC2-dev (2004-01-26):
http://www.informatik.tu-cottbus.de/~tvoigt/php/php_test_results_20040126.txt

Thanks for your reply,
Thomas
 [2004-02-01 10:01 UTC] thekid@php.net
Hrm, the test results contain no ext/sybase_ct related errors.

I guess this is because the tests/ subdirectory is not in the PHP4_3 branch - have a look at http://cvs.php.net/cvs.php/php-src/ext/sybase_ct/tests?login=2, especially bug26407.phpt (you'll also need the two .inc-files and will probably have to change the server name and credentials in test.inc)
 [2004-02-01 14:50 UTC] tvoigt at informatik dot tu-cottbus dot de
Okay, done. It's my first bug report/'make test'-thing, but I'm just beginning to get it ;-)
Thanks for your test case!

Here's the content of bug26407.log (php4-STABLE-200401261030): 
http://www.informatik.tu-cottbus.de/~tvoigt/php/bug26407.log

...and to prove that everything was fine with php-4.3.3:
http://www.informatik.tu-cottbus.de/~tvoigt/php/bug26407.log.php-4.3.3
(Okay, there is a warning about the character set in sybase_connect, making this a "failed" test, too. But the actual test results are as expected. Maybe you want to adapt the test case?)

If you are interested in the other sybase test's results, find the complete output here:
http://www.informatik.tu-cottbus.de/~tvoigt/php/php_test_results_20040201.txt
(#22403 testing failed for my dbo not allowing to create stored procedures in tempdb, sorry.)

Thanks a lot,
Thomas
 [2004-02-06 03:27 UTC] detoma dot alessandro at sea-aeroportimilano dot it
Unfortunatly I don't know to help you, because I have a problem similar to your(failure to compile PHP4.3.4 with sybase 12.0).
I notice however that you have compiled PHP4.3.4 with gdlib on solaris8; Could you say me which version you have used? 
Best regards,
Alex
 [2004-02-08 17:20 UTC] thekid@php.net
4.3.3 doesn't work as expected either. I took your output and diffed it against the expected one:

thekid@friebes:~ > diff -u sybase_test_expected.out sybase_test_4_3_3.out
--- sybase_test_expected.out    Sun Feb  8 23:21:15 2004
+++ sybase_test_4_3_3.out       Sun Feb  8 23:20:12 2004
@@ -1,3 +1,4 @@
+Warning: sybase_connect(): Sybase: Unable to update character set. in /usr/src/php-4.3.3/                 tests/ext/sybase_ct/test.inc on line 55
 bool(true)
 >>> Query: 
     begin transaction
@@ -7,14 +8,8 @@
     commit
     -- anything afterwards will fail, too
   
-<<< Return: resource
-array(1) {
-  [0]=>
-  array(1) {
-    ["computed"]=>
-    string(3) "foo"
-  }
-}
+<<< Return: boolean
+bool(true)
 >>> Query: 
     begin transaction
       -- no result returned...
@@ -31,7 +26,7 @@
     select "bar"   
   
 
-Notice: sybase_query(): Sybase:  Unexpected results, cancelling current in %s/test.inc on                  line %d
+Notice: sybase_query(): Sybase:  Unexpected results, cancelling current in /usr/src/php-4                 .3.3/tests/ext/sybase_ct/test.inc on line 66
 <<< Return: resource
 array(1) {
   [0]=>

 [2004-02-08 18:02 UTC] thekid@php.net
Have been able to reproduce w/ Debian and Sybase-Libraries.

Bug was introduced when the patch in http://bugs.php.net/bug.php?id=23682 was committed.

Am looking into a workaround.
 [2004-02-08 19:03 UTC] thekid@php.net
Please see if the following patches work for you:

* http://sitten-polizei.de/bug26407.diff 
  (patch for CVS head - PHP5)
* http://sitten-polizei.de/bug26407.4.diff 
  (patch for Snapshot/4_3 branch)

make test TEST=ext/sybase_ct is passed now with Sybase-libraries as well as with FreeTDS(download the new test.inc, it contains a fix for the "Sybase: Unable to update character set" warning).

Please make sure I didn't break anything else.
 [2004-02-11 05:42 UTC] tvoigt at informatik dot tu-cottbus dot de
Hi there!

Just applied your patch to a current snapshot (php4-STABLE-200402110830) and it works great! A brief test flight through our various Sybase applications completed without a hassle, so I consider that one done.

Will this patch make it into PHP-4.3.5?

Thanks again and best regards,
Thomas
 [2004-02-15 05:50 UTC] thekid@php.net
This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.

And yes, this patch should make it into PHP 4.3.5.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 14:01:29 2024 UTC