Bug #13694: ocifetchstatement confuses PHP's memory management (or so it seems)

From: chs@baltic-online.de Operating system: Solaris 8 PHP version: 4.0.6 PHP Bug Type: OCI8 related Bug description: ocifetchstatement confuses PHP's memory management (or so it seems) I'm using PHP to access an Oracle database (version 8.0.5). At one point, I execute ocifetchstatement() as follows: <pre> $numrows = ocifetchstatement($stmt, $results); </pre> where $stmt is a statement handle generated earlier, and $results is an empty array. This seems to work fine, and sets $numrows to 1 (the expected result); however, it is, later on, not possible use results - for example, the line <pre> $new_address = $results["UNAME"][0] . "@" . $results["DOMAIN"][0]; </pre> leaves $new_address as an empty string, which definitely cannot be right - it should be, at the least, "@". Doing a var_dump($results) right after the ocifetchstatement() call yields the following output: <pre> array(2) { ["UNAME"]=> array(1) { [0]=> string(18) " </pre> I am not an experienced PHP programmer - in fact, this is the first time I use it at all -, but this definitely does not look right to me. I'm not sure entirely what's happening, but my first guess would be that ocifetchstatement() somehow messes up the internal representation of $results. FYI, here is how the statement handle $stmt was generated: <pre> $stmt = ociparse($conn, "select uname, domain from bodevadm.email, bodevadm.person where (bodevadm.email.pid = bodevadm.person.pid) and (bodevadm.person.name like '%" . $new_nickname . "%')"); </pre> with $conn being the connection handle for the Oracle DB. The problem is also present with other queries, though. Any pointers in case this is a problem on my side rather than a php bug would be greatly appreciated. Also, if you need any additional information, please do not hesitate to contact me. Thank you! -- Edit bug report at: http://bugs.php.net/?id=13694&edit=1