ID: 32859
User updated by: Diomedes_01 at yahoo dot com
Reported By: Diomedes_01 at yahoo dot com
Status: Assigned
Bug Type: OCI8 related
Operating System: Solaris 9 (Server)
PHP Version: 5.0.4
Assigned To: tony2001
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2005-06-13 08:41:26] [EMAIL PROTECTED]
So you tried to write CLOB without setting it empty with EMPTY_CLOB() ?
Am I right?
------------------------------------------------------------------------
[2005-06-13 02:03:35] ab5602 at wayne dot edu
This appears to possibly be parsing problem with the oci_parse function
not returning a real placeholder location. The placeholder :fieldname
does not work if used in this fashion during an sql statement in
v5.0.4, I've found this to work in previous versions:
update table mytable set clob1=:clob;
However, I've found it to work in v5.0.4 if the sql is rewritten such
as:
update table mytable set clob1=empty_clob() returning clob1 as :clob;
------------------------------------------------------------------------
[2005-04-28 19:48:32] Diomedes_01 at yahoo dot com
Unfortunately, my website is behind a firewall and contains company
sensitive information; so I cannot grant access.
The reproducible code is already included; please note that I attempted
to continue using my previous PHP4 code (that worked beforehand) and it
failed. That code was:
<?php
$sql1 = ("begin append_comments(:incident_id,:comments_id);end;");
$sth = OCIParse ( $connection, $sql1 ) or display_main_error();
$clob = OCINewDescriptor ($connection, OCI_D_LOB);
OCIBindByName ( $sth, ":incident_id", &$incident, -1 );
OCIBindByName ($sth, ":comments_id", &$clob, -1, OCI_B_CLOB );
$clob->WriteTemporary($comments);
OCIExecute ($sth, OCI_DEFAULT) or display_main_error();
$clob->close();
$clob->free();
OCIFreeStatement($sth);
?>
When I attempted to execute the above code, I received a fatal error
from PHP indicating that the writeTemporary method was not found.
According to what I read in the documentation, it appears to not be
part of the new OCI class.
So when I followed the documentation and re-implemented the code
following the instructions provided; which by the way, look like so:
(straight from your online help)
<?php
/* Calling PL/SQL stored procedures which contain clobs as input
* parameters (PHP 4 >= 4.0.6).
* Example PL/SQL stored procedure signature is:
*
* PROCEDURE save_data
* Argument Name Type In/Out
Default?
* ------------------------------ ----------------------- ------
--------
* KEY NUMBER(38) IN
* DATA CLOB IN
*
*/
$conn = oci_connect($user, $password);
$stmt = oci_parse($conn, "begin save_data(:key, :data); end;");
$clob = oci_new_descriptor($conn, OCI_D_LOB);
oci_bind_by_name($stmt, ':key', $key);
oci_bind_by_name($stmt, ':data', $clob, -1, OCI_B_CLOB);
$clob->write($data);
oci_execute($stmt, OCI_DEFAULT);
oci_commit($conn);
$clob->free();
oci_free_statement($stmt);
?>
Here is the documentation URL:
http://us2.php.net/manual/en/function.oci-new-descriptor.php
That is when I receive a problem with regards to the 'write' method.
So either this is a bug or a documentation problem; I know the stored
procedure I am using works and that the variables being passed are
valid. It works in SQL*Plus and it works if I revert back to PHP4.
Please advise.
------------------------------------------------------------------------
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
