Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

And can you provide a script sample, and sample schema for me to use in testing?

All right, this snapshot didn't work. It's hard to write a script but here is a good try:

First, a table in my IBM DB2 is created
CREATE TABLE test (
  ID INT,
  DATA CLOB(1M));

Put a string in the CLOB that is greater than 5K, and and ID = 1 or so.

All right, now the script

<?
$linkid = odbc_connect("DBNAME", "USER", "PASSWORD");
$result = odbc_exec($linkid, "SELECT data FROM test WHERE id = 1");

odbc_longreadlen($result, 2000000);
odbc_binmode($result, ODBC_BINMODE_PASSTHRU);

$result = odbc_result($this->result, 1)

echo strlen($result);
?>

This should return the length of your string. If the odbc.defaultlrl is set to 4096, the string is 2000000 chars long. If odbc.defaultlrl is set to 2000000, the string is the correct length.

Actually I tried this with a string that was 28968 chars long, and this it was actually 16388 chars long instead of 2000000. The characters beyond 4096 were corrupted.

Sorry for the exagerated numbers.

Can you try doing something random like changing the CURSOR type to SQL_CURSOR_FORWARD_ONLY?

DB2 doesn't like the DYNAMIC CURSOR used by PHP for some reason, and I wonder if thats the case.  I'm unable to reproduce this behavior here locally though, so it might just be a DB2 specific problem.

How do I do that?

odbc_set_option.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.