ID:               20861
 Updated by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
-Status:           Assigned
+Status:           Closed
 Bug Type:         Sybase-ct (ctlib) related
 Operating System: Linux
 PHP Version:      4.3.0RC2
 Assigned To:      thekid
 New Comment:

------ Feedback from original reporter ------
Timm Friebe wrote:
[...]
> Thanks - I've updated the bug. What do you think? 
> Should I remove the notice?

Hum, after getting a closer look at the problem, i've realized that
i've been fooled by another new features of PHP4.3 that breaks our apps
a bit later :
Dispite new sybase notice, i got expected result as you wrote it in
#20861 (not what i figured out at first look).

So #20861 is boggus. Sorry for  the false alarm.

About the notice itself, i haven't, personaly, any requirement since,
except for debuging purpose, all our sybase_query are @ prefixed (don't
want any sql print out to users in case of errors). Maybe PHP4.3 should
be shipped with a "BC changes" file that stat this one?

Regards,
Christophe.


Previous Comments:
------------------------------------------------------------------------

[2002-12-07 13:51:51] [EMAIL PROTECTED]

<?php
/* Script to reproduce bug #20861
 *
 * $Id$
 */
 
  ini_set('sybct.min_server_severity', 11);
  $db= sybase_connect('gurke', '******', '******');
  sybase_select_db('tempdb', $db);
  
  // var_dump(sybase_query('
  //  create procedure test_bug
  //  @input int
  //  AS
  //  BEGIN
  //   set nocount on
  // 
  //   select @input 'result'
  //   return 2
  //  END
  // ', $db));

  // This doesn't print out the error message
  $q= sybase_query('test_bug 1', $db);
  while ($data= sybase_fetch_object($q)) {
    var_dump($q, $data);
  }

  // This actually prints out the warning message as
  // we have two resultsets  
  $q= sybase_query('
        declare @return int
        exec @return= test_bug 1                                
        select @return
  ', $db);
  while ($data= sybase_fetch_object($q)) {
    var_dump($q, $data);
  }
  
  // var_dump(sybase_query('drop procedure test_bug', $db));
  
  sybase_close($db);
?>

------------------------------------------------------------------------

[2002-12-07 08:38:54] [EMAIL PROTECTED]

Well, in earlier versions sybase_ct silently cancelled the unexpected
results, now it will inform you it is doing so - I thought it was nice
to be a bit more verbose about things.

------------------------------------------------------------------------

[2002-12-06 10:48:02] [EMAIL PROTECTED]

After some more test, i can get the notice (notice -> no result)
without "set nocount on". Don't have pushed further since the procedure
involved is about 400 lines with call to others procedures.
So, just to add that "set nocount on" is a case, not the only one, that
trigger the error.

------------------------------------------------------------------------

[2002-12-06 09:53:00] [EMAIL PROTECTED]

Test script : 

<?
$sy = sybase_pconnect('DBHOST', 'user', 'pass');
sybase_select_db('MyDB', $sy);
sybase_query("test_bug 1", $sy);
?> 

produce : 

Notice: sybase_query() [http://www.php.net/function.sybase-query]:
Sybase:  Unexpected results, cancelling current in - on line 4

with test_bug defined as follow : 

create procedure test_bug
@input int
AS
BEGIN
 set nocount on

 select @input 'result'
 return 2
END

Removing the "set nocount on" lead to expected result but, of course,
in real wold sp, the nocount option is rarely used for fun...

Build with Sybase ctclient v12.5
Works perfectly well with 4.2.3 and previous.



------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=20861&edit=1

Reply via email to