#30690 [Opn]: Resource handle from ibase_execute becomes invalid after return

2005-02-09 Thread kobaz at kobaz dot net
 ID:   30690
 User updated by:  kobaz at kobaz dot net
 Reported By:  kobaz at kobaz dot net
 Status:   Open
 Bug Type: InterBase related
 Operating System: Linux 2.6.5
 PHP Version:  4.3.9
 New Comment:

Er, and of course add the extra global variable, but you get the point.


Previous Comments:


[2005-02-09 20:32:36] kobaz at kobaz dot net

I have a workaround for this bug:

$PQUERY = array();
$curpquery = 0;


function DB_PQuery ($sql, $data) {
  global $PQUERY, $conn;
  
  $PQUERY[$curpquery] = ibase_prepare($conn, $sql);
  $result = ibase_execute($PQUERY[$curpquery], $data);

  $curpquery++;
  return $result;
}

I agree with the previous poster that the result from prepare being
destroyed after it goes out of scope is very inconsistant with the rest
of the database interfaces for php and makes coding for interbase
awkward.



[2005-02-09 18:16:08] [EMAIL PROTECTED]

While this behavior may be intentional on your part, I strongly request
it be changed.

1) No other DBMS extension in PHP does this.
2) This makes writing programs using ibase very difficult.
3) This makes it impossible to write abstraction packages, such as PEAR
DB (which I'm the lead of).



[2004-11-07 14:21:36] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

When $prepare goes out of scope, it is cleaned up along with all the
resources that depend on it. That includes any results that it
created.




[2004-11-05 02:16:40] kobaz at kobaz dot net

Description:

Resource handle from ibase_execute becomes invalid after return

Reproduce code:
---
$conn = ibase_connect('localhost:db', 'SYSDBA', 'pass');

function DB_PQuery ($sql, $data) {
  global $conn;
  
  $prepare = ibase_prepare($conn, $sql);
  $result = ibase_execute($prepare, $data);

  //$A = ibase_fetch_assoc($result);  // uncommenting this will
show resource is valid here
 
  //print_r($A);   


  
  // after this function returns, the return value is no longer a valid
resource

  return $result;
}
   
$result = DB_PQuery("SELECT * FROM testing WHERE a = ?", '1');

$A = ibase_fetch_assoc($result); // fails with: invalid statement
handle 
   
print_r($A);


Expected result:

The ibase_fetch_assoc should be successful after DB_PQuery returns.

Actual result:
--
Before DB_PQuery returns, $result is a valid resource handle that can
be used with ibase_fetch_assoc successfully.

After DB_PQuery returns, the return value is not a valid resource
handle despite that nothing in the script has modified it.





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


#30690 [Opn]: Resource handle from ibase_execute becomes invalid after return

2005-02-09 Thread kobaz at kobaz dot net
 ID:   30690
 User updated by:  kobaz at kobaz dot net
 Reported By:  kobaz at kobaz dot net
 Status:   Open
 Bug Type: InterBase related
 Operating System: Linux 2.6.5
 PHP Version:  4.3.9
 New Comment:

I have a workaround for this bug:

$PQUERY = array();
$curpquery = 0;


function DB_PQuery ($sql, $data) {
  global $PQUERY, $conn;
  
  $PQUERY[$curpquery] = ibase_prepare($conn, $sql);
  $result = ibase_execute($PQUERY[$curpquery], $data);

  $curpquery++;
  return $result;
}

I agree with the previous poster that the result from prepare being
destroyed after it goes out of scope is very inconsistant with the rest
of the database interfaces for php and makes coding for interbase
awkward.


Previous Comments:


[2005-02-09 18:16:08] [EMAIL PROTECTED]

While this behavior may be intentional on your part, I strongly request
it be changed.

1) No other DBMS extension in PHP does this.
2) This makes writing programs using ibase very difficult.
3) This makes it impossible to write abstraction packages, such as PEAR
DB (which I'm the lead of).



[2004-11-07 14:21:36] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

When $prepare goes out of scope, it is cleaned up along with all the
resources that depend on it. That includes any results that it
created.




[2004-11-05 02:16:40] kobaz at kobaz dot net

Description:

Resource handle from ibase_execute becomes invalid after return

Reproduce code:
---
$conn = ibase_connect('localhost:db', 'SYSDBA', 'pass');

function DB_PQuery ($sql, $data) {
  global $conn;
  
  $prepare = ibase_prepare($conn, $sql);
  $result = ibase_execute($prepare, $data);

  //$A = ibase_fetch_assoc($result);  // uncommenting this will
show resource is valid here
 
  //print_r($A);   


  
  // after this function returns, the return value is no longer a valid
resource

  return $result;
}
   
$result = DB_PQuery("SELECT * FROM testing WHERE a = ?", '1');

$A = ibase_fetch_assoc($result); // fails with: invalid statement
handle 
   
print_r($A);


Expected result:

The ibase_fetch_assoc should be successful after DB_PQuery returns.

Actual result:
--
Before DB_PQuery returns, $result is a valid resource handle that can
be used with ibase_fetch_assoc successfully.

After DB_PQuery returns, the return value is not a valid resource
handle despite that nothing in the script has modified it.





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


#30690 [NEW]: Resource handle from ibase_execute becomes invalid after return

2004-11-04 Thread kobaz at kobaz dot net
From: kobaz at kobaz dot net
Operating system: Linux 2.6.5
PHP version:  4.3.9
PHP Bug Type: InterBase related
Bug description:  Resource handle from ibase_execute becomes invalid after return

Description:

Resource handle from ibase_execute becomes invalid after return

Reproduce code:
---
$conn = ibase_connect('localhost:db', 'SYSDBA', 'pass');

function DB_PQuery ($sql, $data) {
  global $conn;
  
  $prepare = ibase_prepare($conn, $sql);
  $result = ibase_execute($prepare, $data);

  //$A = ibase_fetch_assoc($result);  // uncommenting this will show
resource is valid here
 
  //print_r($A);  
  
  
  // after this function returns, the return value is no longer a valid
resource  
  
  return $result;
}
   
$result = DB_PQuery("SELECT * FROM testing WHERE a = ?", '1');

$A = ibase_fetch_assoc($result); // fails with: invalid statement handle  
  
print_r($A);


Expected result:

The ibase_fetch_assoc should be successful after DB_PQuery returns.

Actual result:
--
Before DB_PQuery returns, $result is a valid resource handle that can be
used with ibase_fetch_assoc successfully.

After DB_PQuery returns, the return value is not a valid resource handle
despite that nothing in the script has modified it.

-- 
Edit bug report at http://bugs.php.net/?id=30690&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=30690&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30690&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30690&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30690&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30690&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=30690&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=30690&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=30690&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30690&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=30690&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30690&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30690&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30690&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=30690&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30690&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=30690&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30690&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=30690&r=float
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=30690&r=mysqlcfg