A proper fix would actually take the length of the  
statement string that is extracted in "odbc_exec" via the  
call "zend_parse_parameters".  That length should be  
passed as additional parameter to "_php_db2_do_prepare" 
and used in that function.  Otherwise, the explicit 
SQL_NTS used in the call to "SQLPrepare" will cause DB2 to 
search for the end of the string, and the wrong end will 
be found, i.e. the one inside the parameter string for the 
VARCHAR column. 
 
p.s: What is the reason for not using SQLExecDirect for 
db2_exec?

Knut, that's exactly what I was thinking. Assigning to Kellen to investigate how painful it will be to handle this the right way.

BTW, Larry -- just out of interest, is there a particular reason you need to insert NULL characters as part of a string? Normally those would turn up as part of a binary file (like a JPEG), which it is much more efficient to insert using db2_bind_param() and the DB2_PARAM_FILE constant.

I'm actually trying out a relatively simple patch I whipped together -- also fixing a few other areas where we use SQL_NTS rather than the explicit length of the string. Will commit if it seems to improve the situation. However, PHP might be interfering somewhat, as I'm still seeing the input strings getting truncated at the \0 character on the database side.

Knut, as to why we explicitly call SQLPrepare and SQLExecute for each db2_exec() statement rather than calling SQLExecDirect -- preparing the statement gives the server a chance to reuse the same access plan as the last time the statement was prepared and executed. Given the nature of PHP applications, there aren't a lot of adhoc queries being executed in a typical Web app, so there is a potentially significant performance gain to be realized by preparing each statement.

Okay, committed the patch for nulls in strings. Please try it out in the next snapshot.

Larry, is the db2_stmt_errormsg() corruption a separate issue (does it occur with every statement), or does it only occur for you with these cases of trying to insert strings that contain nulls?

Sorry if this post appears twice... my first attempt seems to have disappeared.

This field in Gallery is used to hold free-form User-entered data... from single characters to (up to 8k) strings like entire articles or maybe even code samples?  One of their Unit Tests tests inserting a string with a null, and it's failing on DB2.  They tell me that truncation is fine... they only diff the results up to the first null.  So I guess it's a matter of whatever DB2 *should* do with nulls... truncate or preserve.

The message corruption is a separate issue; I see it every time I print any error message.

Thanks again, folks.

Larry confirmed in a separate message that the NULL characters in an SQL statement are handled acceptably with the latest patch. Changing summary to reflect remaining focus of this bug on error message corruption from db2_*_errormsg() on Windows.

To be completely accurate, the entire string is inserted, preserving the null '\0'.  Doing a SELECT of that column appears like it is truncated, but it is actually not... DB2's CLP is now stumbling over the null.  Doing a SELECT LENGTH() of the column confirms that the entire string was inserted.

Checked in a nice little hack to fix the corruption on Windows. We were removing \n from error messages, but of course on Windows linefeeds are \r\n. Not sure why there's a linefeed in the first place, which is why I call this a hack...

This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.

Modified hack to fix error message corruption in db2_*_errormsg().