php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23682 sybase_query and multiple result sets: not returning first row set
Submitted: 2003-05-18 11:26 UTC Modified: 2003-08-28 11:19 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: uk at dataway dot ch Assigned:
Status: Closed Package: Sybase-ct (ctlib) related
PHP Version: 4.3.3 OS: Linux 2.4.21
Private report: No CVE-ID:
 [2003-05-18 11:26 UTC] uk at dataway dot ch
Between php 4.3.0 and php 4.3.2RC2, the behaviour of sybase_query was changed; now, it only looks at the very first result from the server, whereas before it returned the first result set which contained any data.
<p>
I know that similar issues have come up before, and that you comment in the source code that applications shouldn't be doing stuff that returns multiple result sets. The problem is that we have many stored procedures which, although they only return one *data* result set (CS_ROW_RESULT), this is preceded by several dummy results (CS_CMD_SUCCEED or CS_CMD_DONE) due to other commands in the stored procedure.
<p>
I would like to submit that the correct behaviour is in fact the one exhibited by php 4.3.0: if several result sets are returned from the server, then sybase_query should return the first one which actually contains data.
I urge you to consider this, as I can't imagine anyone being more interested in a CS_CMD_DONE than in a following CS_ROW_RESULT.
<p>
Anyway this is the patch I used to get everything working again:
<p>
<pre>
*** php_sybase_ct.c.orig Sun May 18 17:49:26 2003
--- php_sybase_ct.c Sun May 18 17:58:02 2003
***************
*** 1386,1394 ****
       case CS_CURSOR_RESULT:
       case CS_PARAM_RESULT:
       case CS_ROW_RESULT:
-       /* Unexpected results, cancel them. */
       case CS_STATUS_RESULT:
!       ct_cancel(NULL, sybase_ptr->cmd, CS_CANCEL_CURRENT);
        break;

       default:
--- 1386,1405 ----
       case CS_CURSOR_RESULT:
       case CS_PARAM_RESULT:
       case CS_ROW_RESULT:
       case CS_STATUS_RESULT:
!       if (status != Q_RESULT) {
!        result = php_sybase_fetch_result_set(sybase_ptr, buffered, store);
!        if (result == NULL) {
!         ct_cancel(NULL, sybase_ptr->cmd, CS_CANCEL_ALL);
!         sybase_ptr->dead = 1;
!         RETURN_FALSE;
!        }
!        status = Q_RESULT;
!       }
!       else {
!        /* Unexpected results, cancel them. */
!        ct_cancel(NULL, sybase_ptr->cmd, CS_CANCEL_CURRENT);
!       }
        break;

       default:

</pre>

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-05-18 11:44 UTC] sniper@php.net
Provide that patch in unified form (diff -u).

 [2003-05-18 11:55 UTC] uk at dataway dot ch
Here (with a slight correction, CS_STATUS_RESULT
doesn't return a result set)


--- ext/sybase_ct/php_sybase_ct.c.orig Sun May 18 17:49:26 2003
+++ ext/sybase_ct/php_sybase_ct.c Sun May 18 18:37:11 2003
@@ -1386,8 +1386,22 @@
      case CS_CURSOR_RESULT:
      case CS_PARAM_RESULT:
      case CS_ROW_RESULT:
-      /* Unexpected results, cancel them. */
+      if (status != Q_RESULT) {
+       result = php_sybase_fetch_result_set(sybase_ptr, buffered, store);
+       if (result == NULL) {
+        ct_cancel(NULL, sybase_ptr->cmd, CS_CANCEL_ALL);
+        sybase_ptr->dead = 1;
+        RETURN_FALSE;
+       }
+       status = Q_RESULT;
+      }
+      else {
+       /* Unexpected results, cancel them. */
+       ct_cancel(NULL, sybase_ptr->cmd, CS_CANCEL_CURRENT);
+      }
+      break;
      case CS_STATUS_RESULT:
+      /* Unexpected results, cancel them. */
       ct_cancel(NULL, sybase_ptr->cmd, CS_CANCEL_CURRENT);
       break;
 [2003-05-27 03:38 UTC] uk at dataway dot ch
This issue is still present in 4.3.2RC4
 [2003-08-19 19:20 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

And possibly update your patch for it.
Is bug #25161 possibly caused by this..?

 [2003-08-28 10:09 UTC] uk at dataway dot ch
The issue is still present in version 4.3.3. This is unsurprising, since the code in question was not changed.

Why don't you want to apply the patch I supplied?
 [2003-08-28 11:19 UTC] sniper@php.net
Patch committed to CVS.

 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Sat Apr 19 17:01:54 2014 UTC