ID: 32859
Comment by: tostinni at yahoo dot fr
Reported By: Diomedes_01 at yahoo dot com
Status: No Feedback
Bug Type: OCI8 related
Operating System: Solaris 9 (Server)
PHP Version: 5.0.4
Assigned To: tony2001
New Comment:
Hi,
I'm using:
Win2k SP4
Wamp Server 1.4.5 RC1 (PHP 5.1.0RC1 with OCI8 enabled)
Oracle9i Enterprise Edition Release 9.2.0.4.0
I tried to make the documentation example for oci_new_descriptor
working and got the same error : OCI_INVALID_HANDLE.
I think there's two errors in the documentation which lead to this bug
:
- you have to execute the statement before doing anything with the clob
descriptor (in fact in example 1, this is correct).
- the stored procedure you present should have parameters set to OUT in
order to bind them to php variables.
Here is a working example.
1/ Create an Oracle table with a CLOB column :
CREATE MY_TABLE (
MY_CLOB CLOB);
2/ Create a stored procedure to UPDATE/INSERT this clob.
CREATE OR REPLACE PROCEDURE SAVE_DATA(THE_CLOB OUT CLOB) IS
BEGIN
INSERT INTO MY_TABLE (MY_CLOB) VALUES (EMPTY_CLOB()) RETURNING
MY_CLOB INTO THE_CLOB;
END;
Note : we can't directly insert the clob into the column, it won't
work. We have to bind the clob to a PHP variable and we need to use the
RETURNING clause and insert an EMPTY_CLOB() to accomplish this.
3/ The php example to insert a value in our table using the procedure
:
<?php
$data = '1234568790';
$conn = oci_connect($user, $password);
$stmt = oci_parse($conn, "begin save_data(:data); end;");
$clob = oci_new_descriptor($conn, OCI_D_LOB);
oci_bind_by_name($stmt, ":data", $clob, -1, OCI_B_CLOB);
oci_execute($stmt, OCI_DEFAULT);
$clob->write($data);
oci_commit($conn);
$clob->free();
oci_free_statement($stmt);
?>
And "1234567890" get inserted in our column.
Previous Comments:
------------------------------------------------------------------------
[2005-09-07 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
------------------------------------------------------------------------
[2005-08-30 13:10:45] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
------------------------------------------------------------------------
[2005-07-14 20:45:20] Diomedes_01 at yahoo dot com
Latest update:
I reverted back to the PHP 4.3.9 environment against the same database.
I was able to successfully handle any lob operations.
When we switched again to PHP 5.0.4 (I rebuilt just to be safe), the
problem still persists.
One thing to note: we are building against the Oracle 10g release but
we had to make some modifications to the configure file to get it to
built against the 32 bit libraries. (The oracle default lib directory
points to the 64 bit libraries that are incompatible with PHP)
We had to perform similar steps when building against Oracle 9i as
well.
Note that building PHP 4.3.9 against the same 10g 32 bit libraries does
work correctly.
------------------------------------------------------------------------
[2005-06-30 00:04:17] [EMAIL PROTECTED]
Please try both your PHP 4.x installation and PHP 5.x installation
against the same database and compare the results.
In addition, your PHP 5.x build should have included the writeTemporary
method. If it is missing from your build, then it sounds like there was
a problem detecting temporary lob support in your environment, and we'd
like to track down the cause of that problem in more detail.
------------------------------------------------------------------------
[2005-06-14 06:55:39] Diomedes_01 at yahoo dot com
With regards to my problem, it was not an issue of the clob not being
initialized. I noticed this problem on CLOBs that were already in
existence. Using a stored procedure we have that updates the value of
the CLOB, that was when I noticed the error.
One thing I will verify with our DBA is the possibility that the recent
upgrade of the database to UTF-8 could be contributing to the problem. I
will try to replicate the issue with PHP 5.0.4 against our older UTF-7
ASCII database.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/32859
--
Edit this bug report at http://bugs.php.net/?id=32859&edit=1
