Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

Also, you don't have to modify your script to make it run with PHP5. Old-style named functions are working in the same way as in PHP4.

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.

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;

So you tried to write CLOB without setting it empty with EMPTY_CLOB() ? Am I right?

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.

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.

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.

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

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".

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.