ID: 13694 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: Solaris 8 PHP Version: 4.0.6 New Comment:
The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Previous Comments: ------------------------------------------------------------------------ [2001-10-17 09:42:06] [EMAIL PROTECTED] 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:57:31] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] i'd rather guess you have some strange characters in the UNAME column? ------------------------------------------------------------------------ [2001-10-16 11:46:52] [EMAIL PROTECTED] 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
