#19364 [Csd]: OCIFetch() is returning garbage on empty resultsets

ID: 19364 User updated by: walovaton@yahoo.com.mx Reported By: walovaton@yahoo.com.mx Status: Closed Bug Type: OCI8 related Operating System: Linux Mandrake 8.2 PHP Version: 4.2.3 New Comment: Was this an old bug? I searched on previous bug reports but I didn't find anything. I'll test the CVS-HEAD version. Thanx for your help. William. Previous Comments: ------------------------------------------------------------------------ [2002-09-12 04:51:11] thies@php.net This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. simply place the oci8.c and php_oci8.h from CVS-HEAD into your 4.2.x and recompile. thx for reporting. ------------------------------------------------------------------------ [2002-09-11 20:00:52] walovaton@yahoo.com.mx Hello, This bug seems to be happening in any 4.2.x series, in my case 4.2.3... but not in 4.1.x series When I executed a query that returns an empty recordset (0 records), the value returned by OCIFetch() (or may be OCIResult()) is random garbage. Some times strange characters, sometimes filed names of the SELECT statement. :-S The sql query is all right, if I print the $sql and copy/paste it in sqlplus... it returns the well known message "no rows selected". Let's see a little example: $conn = OCILogon("user", "pass", "dbstring"); // the id '200' doesn't exists $sql = "select name from customers where id = '200'"; $stmt = OCIParse($conn, $sql); OCIExecute($stmt); OCIFetch($stmt); // $name should be empty, but it contains garbage $name = OCIResult($stmt, "name"); So, like in PHP 4.1.x, I was expecting a null value or something that represents an empty value... not garbage or even important information like a fragment of the SELECT statement. I tried this in both ways: (a) compiling OCI8 as a shared module and (b) compiling OCI8 as part of the php shared object, I got the same result. This is my configure string for php 4.2.3: the (b) way ./configure --with-apxs --disable-static --disable-debug --enable-inline-optimization --prefix=/usr/local/php-4.2.3 --with-config-file-path=/usr/local/php-4.2.3/etc --enable-magic-quotes --with-pear --enable-safe-mode --with-zlib=shared --with-mysql=shared,/usr --with-oci8=/opt/OraHome81 --with-pgsql=shared,/usr --with-gettext=shared --with-regex=system --enable-sysvsem --enable-sysvshm --with-mod_charset --enable-trans-sid --enable-ftp=shared and this is my configure string for php 4.1.2: (works fine) ./configure --with-apxs --disable-static --disable-debug --enable-pic --enable-inline-optimization --prefix=/usr/local --with-zlib --with-config-file-path=/usr/local/etc --enable-magic-quotes --enable-track-vars --enable-safe-mode --with-exec-dir=/usr/bin --with-regex=system --enable-sysvsem --enable-sysvshm --with-mod_charset --enable-force-cgi-redirect --enable-trans-sid --enable-ftp --with-gettext --with-freetype-dir --with-oci8=/opt/OraHome81 --with-mysql=/usr --with-pgsql=/usr I'm using gcc 3.2 (should I use gcc 2.95.X???) I was expecting to make the upgrade to php 4.2.x soon but this strange bug makes me think it twice. I hope this bug report helps you to fix the problem. If you need more information, just ask for it and I'll give you what you need. William. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=19364&edit=1