ID: 27485 Updated by: [EMAIL PROTECTED] Reported By: jseverson at myersinternet dot com -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: Redhat Linux kernel 2.4.18-3 PHP Version: 4.3.4 New Comment:
I can't get your results with this code. In both cases I get empty arrays, if OCI_RETURN_NULLS wasn't used or array of NULLs, if it was. Tested with PHP5-cvs, PHP4-cvs, PHP4.3.3. Previous Comments: ------------------------------------------------------------------------ [2004-03-03 19:27:08] jseverson at myersinternet dot com That does make it so that the var_dump at least shows the null clob column being captured in my result set, but the value of that column is "Null" rather than an Object: array(1) { ["CLOB_1"]=> NULL } ------------------------------------------------------------------------ [2004-03-03 18:58:01] cjbj at hotmail dot com What does using OCIFetchInto($stmt, $table_a_row, OCI_ASSOC+OCI_RETURN_NULLS); give? ------------------------------------------------------------------------ [2004-03-03 16:58:44] jseverson at myersinternet dot com Description: ------------ When handling clob columns in Oracle, PHP is inconsistent in the way that it returns the result set of your query containing that clob column when the clob is null. In one case, the result set contains an Object, and in another case, the result set doesn't contain any Object, even though in both cases, the VALUE of the object after load() is "empty" (column is null). We believe what causes these two different cases is that in the case of an Object being returned, the table being queried had multiple (3) clob columns. The other case when no Object was returned, the table being queried had only one (1) clob column. This makes it nearly impossible to handle your result set data since you can't call the load() function if the object doesn't exist without getting an error, but on the other hand, you can't check whether or not the clob is empty because an Object is present even when the Object has no value. It seems like the correct behavior would be to always return an Object, so that you don't have to first check whether or not the Object is empty or not, before called the load() OCI function. Reproduce code: --------------- //table_a has one clob and clob is null $sql = "select * from test_schema.table_a where primary_key=1"; $stmt = OCIParse($conn_ora, $sql); OCIExecute($stmt, OCI_DEFAULT); OCIFetchInto($stmt, $table_a_row, OCI_ASSOC); OCIFreeStatement($stmt); echo "<pre>"; var_dump($table_a_row); //table_b has multiple clobs (3) and all clobs are null $sql = "select * from test_schema.table_b where primary_key=1"; $stmt = OCIParse($conn_ora, $sql); OCIExecute($stmt, OCI_DEFAULT); OCIFetchInto($stmt, $table_b_row, OCI_ASSOC); OCIFreeStatement($stmt); echo "<pre>"; var_dump($table_b_row); Expected result: ---------------- array(1) { ["CLOB_1"]=> object(OCI-Lob)(1) { ["descriptor"]=> resource(9) of type (oci8 descriptor) } } array(3) { ["CLOB_1"]=> object(OCI-Lob)(1) { ["descriptor"]=> resource(10) of type (oci8 descriptor) } ["CLOB_2"]=> object(OCI-Lob)(1) { ["descriptor"]=> resource(11) of type (oci8 descriptor) } ["CLOB_3"]=> object(OCI-Lob)(1) { ["descriptor"]=> resource(12) of type (oci8 descriptor) } } ------------------ OR ----------------- array(0) { } array(0) { } Actual result: -------------- array(0) { } array(3) { ["CLOB_1"]=> object(OCI-Lob)(1) { ["descriptor"]=> resource(9) of type (oci8 descriptor) } ["CLOB_2"]=> object(OCI-Lob)(1) { ["descriptor"]=> resource(10) of type (oci8 descriptor) } ["CLOB_3"]=> object(OCI-Lob)(1) { ["descriptor"]=> resource(11) of type (oci8 descriptor) } } ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=27485&edit=1