Description: ------------ When using Oracle and MDB, it is not possible to send inserts or updates with empty LOBs, even if the database schema would allow a null value. E.g. a normal insert might look like this: INSERT INTO table (id, lob_value) VALUES ( 1, :lob_value ); But if the LOB value is null or "", this query must be changed into something like the following: INSERT INTO table (id, lob_value) VALUES ( 1, empty_clob() ); or INSERT INTO table (id, lob_value) VALUES ( 1, empty_blob() ); And in this case no descriptor should be created. With the actual stable version of MDB, the result of an empty LOB is an error message saying: "Do query: Could not upload clob data" (oci8.php line 474) Reproduce code: --------------- Try to execute any insert or update query with an empty LOB value. Expected result: ---------------- Execution should be not problem if the LOB value is allowed to be null (DB schema) Actual result: -------------- Error message: "Do query: Could not upload clob data" (oci8.php line 474)

Are you talking about the CVS version of MDB2? Because there NULL handling for Oracle is broken and likely to not be fixed. In MDB and the last MDB2 it should work ok. Have you tried running the test suite?

No, I am using MDB v1.3.0

So are you experiencing this problem with when you pass php null or an empty string or only with empty strings?

I receive this error message in both cases (null and "").

Ok, could you try and run the test suite. You can find it in the tests dir inside your PEAR directory. There is a test that is specifically aimed at testing inserting of null values into LOB's and it worked when I made that release. Also some more information about your particular setup would be helpful. What oracle server are you using? Anything else worth mentioning?

More Information: Oracle is in version 9.2. The executed code is like the following: // create LOB $contentCLOB = array( 'Error' => '', 'Data' => $sessionData ); $clob = $DB->createLob($contentCLOB); if( true === MDB::isError( $clob ) ) { return false; } $query = 'INSERT INTO session (user_id, php_id, ip_address, modified, content) VALUES (?, ?, ?, ?, ?)'; $prep = $DB->prepareQuery( $query ); $DB->setParamText( $prep, 1, $userID ); $DB->setParamText( $prep, 2, $phpID ); $DB->setParamText( $prep, 3, $_SERVER['REMOTE_ADDR'] ); $DB->setParamTimestamp( $prep, 4, date( 'Y-m-d H:i:s' ) ); $DB->setParamClob( $prep, 5, $clob, 'CONTENT' ); $res = $DB->execute( $prep ); $DB->destroyLob($clob); I tried to run the test environment, but it is not able to even create the neccessary table, even though the oracle user can create and drop tables: mdb_manager_testcase : Starting testcreatedatabase ... PEAR-Error MDB Error: not supported: Drop database: database dropping is not supported Failure 1 : Database creation not supported expected TRUE, actual FALSE There were 1 failures for testcreatedatabase There were 0 errors for testcreatedatabase Is there any way to turn on a debug mode or something?

Actually since oracle lacks the concept of a database like other RDBMS have it, MDB emulates it with "users". I will try to get to finding a way to reproduce this sometime this week. However until early next month I will be stressed out.

Finally I got some time to look at things. It seems you are using the API incorrectly: http://cvs.php.net/co.php/pear/MDB/tests/MDB_usage_testcase.php Have a look at line 1067 and following. In MDB its your job to determine if you want to set a value as NULL using the setParamNull() method.

I tought MDB should help the user to use databases more transparently and make them much more "compatible". The problem that I had is, that oracle doesn't know the difference between "" and NULL, as good DBMSes do. Basically I did not want to write NULL values, but empty strings into the CLOB. I hoped, that in case of oracle the driver should make the empty string "" oracle compatible and convert it into a null value automatically. (e.g. in case of MySQL it can stay as it is) I agree to you, that it is my business to use emptyClob, if I want to put a NULL value into the DB. This feature would help to increase compatibility even more.

I have added this feature into MDB2.