Description: ------------ When a $params array is included in a getXxx call (as the documentation indicates is valid and will cause the statement to go through prepare/execute), a null result is returned. I tested this under PHP 4.3.4 and 4.3.3 with DB 1.5.0RC2 against and Oracle 8.1.7 database on Solaris. Reproduce code: --------------- supposing that you have a DB on the backend with appropriate data, this... $param_array = array(147, 1); $sql = "select foo from bar where baz = ? and xyzzy = ?"; $row = $db->getRow($sql, $param_array); should produce the same results as this... $sql = "select foo from bar where baz = 147 and xyzzy = 1"; $row = $db->getRow($sql); or this... $param_array = array(147, 1); $sql = "select foo from bar where baz = ? and xyzzy = ?"; $sth = $db->prepare($sql); $result = $db->execute($sth, $param_array); $row = $result->fetchRow(); Expected result: ---------------- All three phrasings should produce the same value for $row. Actual result: -------------- getRow with params returns a null result while the other two phrasings return valid data.

The problem lies with the freePrepared() method of oci8.php's object. The call to ocifreestatement() within that method trashes the result of the fetch. More investigation coming.

It looks like there's no memory leak when you take out the offending ocifreestatement() call in oci8's freePrepared() method. As I surmised, the resources are being freed up as part of normal garbage collection. I ran with a loop around the fetch with bind vars and after 450,000 fetches, the memory usage was stable (see below). This was the same fetch over and over again. One thing I can't effectively test in isolation is how a wide variety of fetches affect memory use. This may have different results. PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 23909 php 1.3% 0:01.83 1 13 50 2.72M 7.34M 6.82M 41.7M 23909 php 5.5% 0:04.28 1 13 51 2.75M 7.34M 6.83M 41.7M 23909 php 4.1% 0:06.97 1 13 51 2.75M 7.34M 6.83M 41.7M 23909 php 4.1% 0:08.80 1 13 52 2.75M 7.34M 6.84M 41.9M 23909 php 1.4% 0:16.18 1 13 52 2.75M 7.34M 6.84M 41.9M 23909 php 0.7% 0:19.32 1 13 52 2.76M 7.34M 6.84M 41.9M 23909 php 2.2% 2:39.00 1 13 52 2.83M 7.34M 6.91M 41.9M 23909 php 5.1% 2:58.01 1 13 52 2.84M 7.34M 6.92M 41.9M 23909 php 2.7% 4:28.91 1 13 52 2.88M 7.34M 6.96M 41.9M 23909 php 4.2% 6:27.26 1 13 52 2.88M 7.34M 6.96M 41.9M 23909 php 4.8% 7:26.90 1 13 52 2.85M 7.34M 6.96M 41.9M 23909 php 4.1% 7:56.90 1 13 52 2.85M 7.34M 6.96M 41.9M 23909 php 4.1% 8:26.10 1 13 52 2.85M 7.12M 6.96M 41.9M 23909 php 2.0% 9:50.96 1 13 52 2.85M 7.12M 6.96M 41.9M 23909 php 8.6% 11:20.55 1 13 52 2.85M 7.12M 6.96M 41.9M 23909 php 6.0% 12:50.39 1 13 52 2.85M 7.12M 6.96M 41.9M 23909 php 7.0% 13:51.43 1 13 52 2.85M 7.12M 6.96M 41.9M 450,000 fetches The change on 4.3.4's oci8.php: *** oci8.php Sat Nov 22 22:18:43 2003 --- /usr/local/lib/php/DB/oci8.php Tue Nov 11 23: 40:15 2003 *************** *** 246,252 **** if (!is_resource($stmt)) { return false; } ! //ocifreestatement($stmt); unset($this->prepare_tokens[(int)$stmt]); unset($this->prepare_types[(int)$stmt]); unset($this->manip_query[(int)$stmt]); --- 246,252 ---- if (!is_resource($stmt)) { return false; } ! ocifreestatement($stmt); unset($this->prepare_tokens[(int)$stmt]); unset($this->prepare_types[(int)$stmt]); unset($this->manip_query[(int)$stmt]); ***************

Can someone with cvs privs commit this patch?