#27485 [Opn->Fbk]: OCI clob column objects inconsistent in result set
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:
The same results(i.e. allright) with 4.3.4.
By the way, PHP 4.3.4 was released before all these changes you're
talking about, in the early november, 2003.
Previous Comments:
[2004-03-04 12:22:05] jseverson at myersinternet dot com
Can you please try PHP version 4.3.4? We looked at the CVS log for the
OCI changes done and it looks like a lot of work was done in December,
2003 dealing with LOBs, which wouldn't be present in 4.3.3.
Thanks
[2004-03-04 01:59:26] [EMAIL PROTECTED]
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.
[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 "";
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 "";
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
#27485 [Opn->Fbk]: OCI clob column objects inconsistent in result set
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 "";
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 "";
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
