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

From: Date: Wed, 17 Oct 2001 13:42:06 +0000
Subject: Bug #13694 Updated: ocifetchstatement confuses PHP's memory management (or so it seems)
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-68132@lists.php.net to get a copy of this message
ID: 13694 User updated by: chs@baltic-online.de Reported By: chs@baltic-online.de Status: Open Bug Type: OCI8 related Operating System: Solaris 8 PHP Version: 4.0.6 New Comment: This actually does not seem to happen specificially with ocifetchstatement only; fetching the results with ocifetch and then using ociresults to access the columns yields exactly the same problem. Previous Comments: ------------------------------------------------------------------------ [2001-10-16 12:57:31] chs@baltic-online.de This actually does not seem to happen specificially with ocifetchstatement only; fetching the results with ocifetch and then using ociresults to access the columns yields exactly the same problem. ------------------------------------------------------------------------ [2001-10-16 12:10:21] chs@baltic-online.de Actually, no, or at least not to my knowledge. This is what I expected: <pre> SQL> select uname, domain from bodevadm.email where pid = 275; UNAME DOMAIN ------------------------------ ------------------------------ billgates microsoft.com SQL> </pre> I also used this statement inside the php script for testing, but it gave exactly the same error as the original one. ------------------------------------------------------------------------ [2001-10-16 12:05:46] hholzgra@php.net i'd rather guess you have some strange characters in the UNAME column? ------------------------------------------------------------------------ [2001-10-16 11:46:52] chs@baltic-online.de 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 this bug report at http://bugs.php.net/?id=13694&edit=1

« previous php.dev (#68132) next »