|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #47133 php-odbc SQLBindCol() not used correctly
Submitted: 2009-01-17 00:13 UTC Modified: -
Avg. Score:4.6 ± 0.8
Reproduced:33 of 33 (100.0%)
Same Version:11 (33.3%)
Same OS:7 (21.2%)
From: marquis at us dot ibm dot com Assigned:
Status: Open Package: ODBC related
PHP Version: 5.2.8 OS: Fedora 9
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: marquis at us dot ibm dot com
New email:
PHP Version: OS:


 [2009-01-17 00:13 UTC] marquis at us dot ibm dot com
PHP applications that use the iSeries Access for Linux ODBC driver to SELECT CHAR data containing characters outside the invariant character set (for example: "?"), and using a UTF-8 locale, may receive extra garbage data at the end of the character string.
This is caused by PHP passing an insufficient target length on the call to SQLBindCol(). PHP is setting the incorrect buffer length by using SQLColAttributes to return the SQL_COLUMN_DISPLAY_SIZE.

I have seen this behavior on PHP 5.1 and 5.2.6-2
This problem also exists in PHP for Windows.

The iSeries Access for Linux ODBC driver correctly returns error message :
CWB0111 - A buffer passed to a system call is too small to hold return data

However, the ODBC driver will be changed to not return the extra garbage data at the end of the CHAR string when using a connection string keyword option.
PHP applications could then ignore the CWB0111 error message.

For PHP applications using the UTF8 locale to use this workaround and prevent the extra garbage data, the odbc connection must pass in the following connection string keyword:  
DEBUG = 65536

Additional options:
PHP does not calculate all buffer lengths using SQL_COLUMN_DISPLAY SIZE, so, PHP developers could use other SQL column types such as: 
SQL_BINARY, SQL_VARBINARY, SQL_LONGVARBINARY or SQL_LONGVARCHAR. No binding occurs with those data types and SQLGetData() is used to retrieve the value.
For long data it may be neccessary to call PHP ODBC API odbc_longread() ( , because that is the length to be used for the buffer. If less data is available, PHP shrinks the buffer, but if more data is available, truncation will occur.

Ref IBM APAR SE33393

The ideal solution would be for PHP to use the correct buffer length on the call to SQLBindCol().

Reproduce code:
//setlocale(LC_ALL, 'de_DE');
$link = odbc_connect("MySystem","MyUserID","MyPasswd");
$result = odbc_exec($link,"select * from MySchema.MyTable");

$count = 0;
while ($val= odbc_fetch_array($result)) {

print "locale is :/n";

Expected result:
Just return the CHAR string without extra data at the end.
For example:

array(1) {
  string(6) "?   "

Actual result:
array(1) {
  string(40) "?   <bunch of garbage here as well as NULLs>"


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-03-05 09:13 UTC] crypteo at gmail dot com
This is still happening with php 5.3.10
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 01 12:01:29 2024 UTC