php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #56836 Extra null character on result from CLOB column
Submitted: 2006-02-11 18:13 UTC Modified: 2006-02-13 16:08 UTC
From: larry dot menard at rogers dot com Assigned:
Status: Closed Package: ibm_db2 (PECL)
PHP Version: 5.1.1 OS: Windows XP, SP2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
34 + 25 = ?
Subscribe to this entry?

 
 [2006-02-11 18:13 UTC] larry dot menard at rogers dot com
Description:
------------
If I do SELECT from a CLOB column, the result has an unwanted null character (x'0') on the end.

(Actually, I'm running PHP 5.1.2, but couldn't find that version in the popup list on the bug reporting page.)

Running DB2 ESE V8 FP10.

Reproduce code:
---------------
Grab the following script:

http://cpe0013102da23b-cm0f0079804905.cpe.net.cable.rogers.com/misc/testLob.php.txt

Edit the database name, userid and password in it, then run it like:

php TestLob.php ibm_db2

Compare it to ODBC by running it like:

php TestLob.php odbc


Expected result:
----------------
"database" from VARCHAR is 8 bytes long, "database" from CLOB is 8 bytes long.

Actual result:
--------------
"database" from VARCHAR is 8 bytes long, "database " from CLOB is 9 bytes long

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-02-13 10:30 UTC] denials at gmail dot com
Larry doesn't say whether he's using one of the db2_fetch_* functions or db2_result(), but it looks like this problem would occur in both of them.

The problem with db2_result() stems from using RETURN_STRING() instead of RETURN_STRINGL() in line 3210. We already know the length of the string (in_length), so we're better off using RETURN_STRINGL() to return a binary-safe string. This also enables us to avoid adding the extra null that Larry is seeing. See http://php.net/zend.returning for more details on RETURN_STRINGL().

The problem with the db2_fetch_* functions is that in line 3506 an additional null is added to the end of the string before calling add_assoc_stringl (which is a binary safe string function as described in http://www.php.net/manual/en/zendapi-reference.php).

Any chance you can test out a fix for this one today, Kellen?
 [2006-02-13 14:04 UTC] kfbombar at us dot ibm dot com
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.

The null characters at the end of CLOB columns have been fixed in CVS.  Both the db2_fetch_* function and the db2_result functions have been modified for this.
 [2006-02-13 16:08 UTC] larry dot menard at rogers dot com
Thanks, my test script now works as expected.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 00:01:28 2024 UTC