#32859 [Asn]: Error when attempting to write Clob to oracle
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 TypeIn/Out Default? * -- --- -- * KEYNUMBER(38) IN * DATA CLOBIN * */ $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
#32859 [Fbk-Opn]: Error when attempting to write Clob to oracle
ID: 32859 User updated by: Diomedes_01 at yahoo dot com Reported By: Diomedes_01 at yahoo dot com -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: Solaris 9 (Server) PHP Version: 5.0.4 Assigned To: tony2001 New Comment: 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. Previous Comments: [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 TypeIn/Out Default? * -- --- -- * KEYNUMBER(38) IN * DATA CLOBIN * */ $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. [2005-04-28 15:04:53] [EMAIL PROTECTED] 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. [2005-04-27 21:44:58] Diomedes_01 at yahoo dot com Description: I
#32859 [Fbk-Opn]: Error when attempting to write Clob to oracle
ID: 32859 User updated by: Diomedes_01 at yahoo dot com Reported By: Diomedes_01 at yahoo dot com -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: Solaris 9 (Server) PHP Version: 5.0.4 New Comment: 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 TypeIn/Out Default? * -- --- -- * KEYNUMBER(38) IN * DATA CLOBIN * */ $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. Previous Comments: [2005-04-28 15:04:53] [EMAIL PROTECTED] 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. [2005-04-27 21:44:58] Diomedes_01 at yahoo dot com Description: I am receiving errors after upgrading from php 4.3.9 to php 5.0.4 when attempting to upload a clob to my Oracle database. The code has already been modified to follow the PHP 5 paradigm; but it is refusing to function. Code is as follows: Reproduce code: --- $sql1 = (begin append_comments(:incident_id,:comments_id);end;); $sth = oci_parse ( $connection, $sql1 ) or display_main_error(); $clob = oci_new_descriptor ($connection, OCI_D_LOB); oci_bind_by_name ( $sth, :incident_id, $incident ); oci_bind_by_name ($sth, :comments_id, $clob, -1, OCI_B_CLOB ); $clob-write($comments); oci_execute ($sth, OCI_DEFAULT) or display_main_error(); oci_commit($connection); $clob-free(); oci_free_statement($sth); Expected result: The above code should properly insert the clob into the Oracle database. The code executed correctly in php4.3.9 and the stored procedure being used functions normally in SQL*Plus. Actual result: -- I receive the following warnings from PHP when attempting to execute the code: Warning: OCI-Lob::write() [function.write]: OCILobGetLength: OCI_INVALID_HANDLE in /www/htdocs/EtrackTest/oracle_update.php on line 218 Warning: oci_execute() [function.oci-execute]: OCIStmtExecute: ORA-22275: invalid LOB locator specified ORA-06512: at SYS.DBMS_LOB, line 366 ORA-06512: at ETRACK.APPEND_COMMENTS, line 14 ORA-06512
#32880 [NEW]: Unable to properly convert from ISO-8859-1 to UTF-8
From: Diomedes_01 at yahoo dot com Operating system: Solaris 9 PHP version: 5.0.4 PHP Bug Type: Strings related Bug description: Unable to properly convert from ISO-8859-1 to UTF-8 Description: I am unable to properly encode certain strings from ISO-8859-1 to UTF-8. I have tried using utf8_encode, mb_convert_encoding and iconv with no success. The code I am attempting this on is as follows: Reproduce code: --- ?php $main_test_string = référendum sur la Constitution européenne; $string_test = mb_detect_encoding($main_test_string, 'UTF-8, ISO-8859-1'); echo Encoding used: $string_testbr; // Properly displays ISO-8859-1 // First try converting with iconv $iconv_test = iconv(ISO-8859-1, UTF-8, $main_test_string); echo Iconv test: $iconv_testbr; // Displays nothing. No data whatsoever // Now try converting with mb_convert_encoding $mb_test = mb_convert_encoding($main_test_string, UTF-8, ISO-8859-1); $string_test2 = mb_detect_encoding($mb_test, 'UTF-8, ISO-8859-1'); echo Encoding used: $string_test2br; // Indicates string is now UTF-8 encoded (which is wrong) echo MB Test convert value: $mb_testbr; // Displays: référendum sur la Constitution européenne; doesn't look like UTF-8 to me // Finally try utf8_encode $utf8_encode_test = utf8_encode($main_test_string); $string_test3 = mb_detect_encoding($textfieldabstract, 'UTF-8, ISO-8859-1'); echo Encoding used: $string_test3br; // Indicates string is now UTF-8 encoded (which is wrong) echo Abstract post conversion: $utf8_encode_testbr; // Same as before, displays: référendum sur la Constitution européenne ? Expected result: I should be seeing UTF-8 (Unicode) translated text of the style: '#917;#955;#955;#951;#957;#953;' Note that the above does work for non-latin based character sets like chinese, japanese, russian, greek, etc. Actual result: -- What I am seeing is the following string: référendum sur la Constitution européenne Definately not UTF-8. Could be Klingon. :-) I will admit I am not a Unicode master but this is certainly quite puzzling. According to the documentation, iconv is supposed to work in this case but it is not displaying any data. I am running PHP 5.0.4 with iconv enabled. (I see it in my phpinfo output) Please advise. -- Edit bug report at http://bugs.php.net/?id=32880edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32880r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32880r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32880r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32880r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32880r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32880r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32880r=needscript Try newer version: http://bugs.php.net/fix.php?id=32880r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32880r=support Expected behavior: http://bugs.php.net/fix.php?id=32880r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32880r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32880r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32880r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32880r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32880r=dst IIS Stability: http://bugs.php.net/fix.php?id=32880r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32880r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32880r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32880r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32880r=mysqlcfg
#32859 [NEW]: Error when attempting to write Clob to oracle
From: Diomedes_01 at yahoo dot com Operating system: Solaris 9 (Server) PHP version: 5.0.4 PHP Bug Type: OCI8 related Bug description: Error when attempting to write Clob to oracle Description: I am receiving errors after upgrading from php 4.3.9 to php 5.0.4 when attempting to upload a clob to my Oracle database. The code has already been modified to follow the PHP 5 paradigm; but it is refusing to function. Code is as follows: Reproduce code: --- $sql1 = (begin append_comments(:incident_id,:comments_id);end;); $sth = oci_parse ( $connection, $sql1 ) or display_main_error(); $clob = oci_new_descriptor ($connection, OCI_D_LOB); oci_bind_by_name ( $sth, :incident_id, $incident ); oci_bind_by_name ($sth, :comments_id, $clob, -1, OCI_B_CLOB ); $clob-write($comments); oci_execute ($sth, OCI_DEFAULT) or display_main_error(); oci_commit($connection); $clob-free(); oci_free_statement($sth); Expected result: The above code should properly insert the clob into the Oracle database. The code executed correctly in php4.3.9 and the stored procedure being used functions normally in SQL*Plus. Actual result: -- I receive the following warnings from PHP when attempting to execute the code: Warning: OCI-Lob::write() [function.write]: OCILobGetLength: OCI_INVALID_HANDLE in /www/htdocs/EtrackTest/oracle_update.php on line 218 Warning: oci_execute() [function.oci-execute]: OCIStmtExecute: ORA-22275: invalid LOB locator specified ORA-06512: at SYS.DBMS_LOB, line 366 ORA-06512: at ETRACK.APPEND_COMMENTS, line 14 ORA-06512: at line 1 in /www/htdocs/EtrackTest/oracle_update.php on line 219 The code I use is virtually identical to what exists in the PHP documentation. -- Edit bug report at http://bugs.php.net/?id=32859edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32859r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32859r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32859r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32859r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32859r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32859r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32859r=needscript Try newer version: http://bugs.php.net/fix.php?id=32859r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32859r=support Expected behavior: http://bugs.php.net/fix.php?id=32859r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32859r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32859r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32859r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32859r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32859r=dst IIS Stability: http://bugs.php.net/fix.php?id=32859r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32859r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32859r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32859r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32859r=mysqlcfg
