php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #63949 selects on long varchar fields returns empty with PDO ODBC
Submitted: 2013-01-09 00:27 UTC Modified: 2020-12-27 04:22 UTC
Votes:36
Avg. Score:4.8 ± 0.5
Reproduced:35 of 35 (100.0%)
Same Version:5 (14.3%)
Same OS:6 (17.1%)
From: toebs at pubsqrd dot com Assigned: cmb (profile)
Status: No Feedback Package: PDO ODBC
PHP Version: 5.4.10 OS: Amazon Linux
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: toebs at pubsqrd dot com
New email:
PHP Version: OS:

 

 [2013-01-09 00:27 UTC] toebs at pubsqrd dot com
Description:
------------
In short, it looks like selects on varchars columns which are long (some indeterminate value, 1000 certainly qualifies) fail with PDO via ODBC.

The same query works with the following methods;

1. PDO using mysql
2. unixODBC directly (via isql)
3. vsql (the Vertica native command line client)
4. PHP ODBC

The error given is that column binding has not occurred.  This is odd - note in the script I have deliberately used fetchColumn() to avoid the need for column binding, in an effort to avoid this error.

This problem was found in 5.3.19 and also in 5.4.9.


Test script:
---------------
create table tobytest
(
  string_short varchar(50),
  string_long varchar(1000)
);

insert into tobytest (string_short, string_long) values ('short', 'long');

<?php

$db_connect = new PDO( "odbc:pubsquared", "dbadmin", "big science" );
$db_connect -> setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$q = $db_connect->prepare( "select string_long from tobytest" );
$q->execute();

$r = $q->fetchColumn();
print $r;

?>



Expected result:
----------------
[root@ip-1-1-1-1 ~]# php test4.php
long
[root@ip-1-1-1-1 ~]#


Actual result:
--------------
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[SL010]: <<Unknown error>>: 0 [unixODBC][Driver Manager]SQLBindCol returned SQL_ERROR on a attempt to bind a internal buffer (SQLFetchScroll[0] at /builddir/build/BUILD/php-5.4.9/ext/pdo_odbc/odbc_stmt.c:537)' in /root/test4.php:8
Stack trace:
#0 /root/test4.php(8): PDOStatement->fetchColumn()
#1 {main}

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-01-09 08:41 UTC] toebs at pubsqrd dot com
-: toes at pubsqrd dot com +: toebs at pubsqrd dot com
 [2013-01-09 08:41 UTC] toebs at pubsqrd dot com
Typo in the email address.  Correct email is "toebs@pubsqrd.com".
 [2013-01-30 00:08 UTC] paul dot posts at gmail dot com
Also seeing this using pdo+odbc with MSSQL 2012. varchar(max) and varchar(256) 
columns were both causing heap overflow. Casting the columns to a text column 
resulted in returning the correct data as a workaround.
 [2013-01-30 00:38 UTC] paul dot posts at gmail dot com
Apologies, our testing showed that cast to text was not a viable workaround.
 [2013-02-20 06:22 UTC] cyberitas at gmail dot com
We're also seeing the same sigsegv mentioned in the previous comment with pdo+odbc 
with MS-SQL via freetds ODBC.  Selecting from a column defined as varchar(256) any 
of the fetch functions lead to a segfault. 


Program received signal SIGSEGV, Segmentation fault.
0x00002aaab393010b in ?? () from /usr/lib64/libodbccr.so.1
(gdb) info stack
#0  0x00002aaab393010b in ?? () from /usr/lib64/libodbccr.so.1
#1  0x00002aaab013648d in SQLGetData () from /usr/lib64/libodbc.so.1
#2  0x00002aaab059d288 in ?? () from /usr/lib64/php/modules/pdo_odbc.so
#3  0x00002aaab038d920 in ?? () from /usr/lib64/php/modules/pdo.so
#4  0x00002aaab038e56e in ?? () from /usr/lib64/php/modules/pdo.so
#5  0x00002aaab038f7fc in ?? () from /usr/lib64/php/modules/pdo.so
#6  0x00000000005e78e9 in ?? ()
#7  0x00000000005bd9ab in execute ()
#8  0x0000000000599f45 in zend_execute_scripts ()
#9  0x000000000054ad48 in php_execute_script ()
#10 0x0000000000622cde in ?? ()
#11 0x00000034b5e1d9c4 in __libc_start_main () from /lib64/libc.so.6
#12 0x0000000000421789 in _start ()
 [2014-01-01 12:34 UTC] felipe@php.net
-Package: PDO related +Package: PDO ODBC
 [2017-04-14 18:42 UTC] daniel at ringhisercomputersolutions dot com
This problem still exists in version 7.0.15. Why is this not being fixed?
 [2018-05-30 19:11 UTC] ivaldo dot oliveira at gmail dot com
This problem still exists in version 7.2.2. My column is varchar (300) and my database is the Intersystems Cache.
Thanks for help.
 [2020-09-28 13:54 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2020-09-28 13:54 UTC] cmb@php.net
I cannot reproduce this with current PHP 7.3 and the ODBC Driver
17 for SQL Server.  Can anybody else reproduce the segfault with
any of the actively supported PHP versions[1]?  If so, we need to
know which database and ODBC driver, and which version of PHP you
are using, and also an ODBC trace of the execution of a well
defined script.

[1] <https://www.php.net/supported-versions.php>
 [2020-10-11 04:22 UTC] php-bugs at lists dot php dot net
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 "Re-Opened". Thank you.
 [2020-12-17 08:13 UTC] hldh214 at gmail dot com
This problem in my case does not raise any exception
but simply return null on some "large" columns

Environment:
--------------
php -v
PHP 8.0.0 (cli) (built: Nov 24 2020 17:04:03) ( NTS gcc x86_64 )
Copyright (c) The PHP Group
Zend Engine v4.0.0-dev, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.0, Copyright (c), by Zend Technologies

build with pdo_odbc: --with-pdo-odbc=unixODBC,/usr

database: Vertica Analytic Database v9.2.0-3


Reproduce code:
---------------
create table bug_63949
(
    A varchar(80)   NOT NULL,
    B tinyint       NOT NULL,
    C varchar(100)  NOT NULL,
    D smallint      NOT NULL,
    E varchar(1024) NOT NULL,
    F varchar(255)  NOT NULL,
    G varchar(255)  NOT NULL,
    H varchar(1000) NOT NULL,
    I varchar(100)  NOT NULL,
    J tinyint       NOT NULL,
    K varchar(255)  NULL
);

insert into bug_63949 values ('A', '1', 'C', '2', 'E', 'F', 'G', 'H', 'I', '3', 'K');

//////////////////////////////////////////////////////////////
<?php
// https://bugs.php.net/bug.php?id=63949
// https://stackoverflow.com/q/48685059/6266737
// https://stackoverflow.com/q/42301688/6266737

$sql = "select * from bug_63949;";

$ch = new PDO("odbc:VerticaDSNunixodbc");
$stmt = $ch->prepare($sql);
$stmt->execute();
$res = $stmt->fetch(PDO::FETCH_ASSOC);
var_dump($res);

//////////////////////////////////////////////////////////////

Expected result:
----------------
array(11) {
  ["A"]=>
  string(1) "A"
  ["B"]=>
  string(1) "1"
  ["C"]=>
  string(1) "C"
  ["D"]=>
  string(1) "2"
  ["E"]=>
  string(1) "E"
  ["F"]=>
  string(1) "F"
  ["G"]=>
  string(1) "G"
  ["H"]=>
  string(1) "H"
  ["I"]=>
  string(1) "I"
  ["J"]=>
  string(1) "3"
  ["K"]=>
  string(1) "K"
}

Actual result:
--------------
array(11) {
  ["A"]=>
  string(1) "A"
  ["B"]=>
  string(1) "1"
  ["C"]=>
  string(1) "C"
  ["D"]=>
  string(1) "2"
  ["E"]=>
  NULL
  ["F"]=>
  NULL
  ["G"]=>
  NULL
  ["H"]=>
  NULL
  ["I"]=>
  NULL
  ["J"]=>
  NULL
  ["K"]=>
  NULL
}

My temporary solution:
----------------------
https://stackoverflow.com/a/57820264/6266737
 [2020-12-17 13:05 UTC] cmb@php.net
-Status: No Feedback +Status: Feedback
 [2020-12-17 13:05 UTC] cmb@php.net
Thanks!  That is somewhat helpful to analyze the problem.  While I
still cannot reproduce, I have at least some clue.  Obviously, the
retrieval of the column as long data does not work for you.  The
OP had the same issue, but claimed that it would work with
"native" ODBC extension.  That extension does basically the same
as PDO, but defaults to a length of 4096, while PDO defaults to
256.  Increasing that may make sense anyway, but would only
mitigate the problem.

Actually, the code retrieving the long data doesn't provide
diagnostics to understand what really happens, so could you please
provide an ODBC trace of running the script?

Also, set PDO::ATTR_ERRMODE to PDO::ERRMODE_EXCEPTION to not miss
any error information.
 [2020-12-27 04:22 UTC] php-bugs at lists dot php dot net
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 "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 15:01:30 2024 UTC