Skip to content

ODBC bug fix for varchars returning with length zero #348

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

ODBC bug fix for varchars returning with length zero #348

wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented May 23, 2013

This is a fix for this issue filed a long time ago and submitted to the original bug tracker site https://bugs.php.net/bug.php?id=54169

This bug also currently affects vertica DB.

From the original description

Description:

I found an issue this week that exists in both odbc and pdo_odbc with
SQL Server. The ODBC implemention of Windows returns 0 as the length
for for varchar(max) and nvarchar(max). This makes the allocation of
the strings incorrect and you get back garbage pointers for the
contents.

This was a pretty easy fix for pdo_odbc, simply check if the colsize
is returned as 0 and the type is one of the varchar types, if so
always treat it as a column with "long" data. This works perfectly
without breaking things. Attached is a patch that works for both 5.3
and trunk, includes an additional test for the issue.

ODBC shows the same issue - don't have a fix for that

Occurs in all versions of PHP

There are multiple bug reports concerning this and related to it - I'll try to gather them all up (later)

Test script:

$db = new PDO('odbc:yourdsnhere', 'username', 'password');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db->exec('CREATE TABLE testing(id INT NOT NULL PRIMARY KEY, data varchar(max))');
$insert = $db->prepare('INSERT INTO testing VALUES (?, ?)');
$insert->execute(array(1, str_repeat('i', 500)));
$stmt = $db->query('select * from testing');
var_dump($stmt->fetchAll());

unset($db, $insert, $smt);

// This shows the same issue in odbc
$db = odbc_connect ('yourdsnhere', 'username', 'password');
$stmt = odbc_exec($db, 'select * from testing');
var_dump(odbc_fetch_array($stmt));

Expected result:

array(1) { [0]=> array(4) { ["id"]=> string(1) "1" [0]=> string(1) "1" ["data"]=> string(500) "iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii" [1]=> string(500) "iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii" } }

Same for the odbc call

Actual result:

array(1) { [0]=> array(4) { ["id"]=> string(1) "1" [0]=> string(1) "1" ["data"]=> string(500) "�-\�p-\�!�������ˆòE�����������ii����iiii!���!���select * from foo�iiiiii����!�������hall�iiiiiii!�������ÀùE�����������ii��������1���!���­|a�����ìòE��áE������ðE���������stmt����!���1���(áE���������������������1���!�����������������������óE�àõE��$E� ©"�����1���1������������óE�����àõE�������������€�������1���1��������������������óE���������@éE�øëE�����!���1���àóE�ô�����������������������!���iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii" [1]=> string(500) "�-\�p-\�!�������ˆòE�����������ii����iiii!���!���select * from foo�iiiiii����!�������hall�iiiiiii!�������ÀùE�����������ii��������1���!���­|a�����ìòE��áE������ðE���������stmt����!���1���(áE���������������������1���!�����������������������óE�àõE��$E� ©"�����1���1������������óE�����àõE�������������€�������1���1��������������������óE���������@éE�øëE�����!���1���àóE�ô�����������������������!���iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii" } } array(2) { ["id"]=> string(1) "1" ["data"]=> string(500) "�èE�8öE�p�������HöE�HöE�$.\�päE�����icrosoft][SQL Server Native Client 10.0]String data, right truncation�����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������" }

@smalyshev
Copy link
Contributor

Having some test for this fix would be nice.

@ghost
Copy link
Author

ghost commented Jun 17, 2013

The patch doesn't work, the bug still exists after applying it. There is a workaround by setting the long read length to something high like 10000, and just pray you never read past 10000 bytes.

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant