php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35003 Warning: PDOStatement::fetch(): column 0 data was too large for buffer and was
Submitted: 2005-10-27 18:22 UTC Modified: 2016-03-08 01:35 UTC
From: derick@php.net Assigned: wez (profile)
Status: Closed Package: PDO OCI
PHP Version: 5.1.0RC3 OS: Linux - Fedora Core 1
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: derick@php.net
New email:
PHP Version: OS:

 

 [2005-10-27 18:22 UTC] derick@php.net
Description:
------------
Strange warning when fetching data from an Oracle DB with PDO:
"column N data was too large for buffer and was truncated to fit it"


Reproduce code:
---------------
Environment:
============
PHP version: 5.1.0RC3
Server version: Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
Client libraries: oracle-instantclient 10.1.0.4
OS: Fedora Core 1

How to reproduce:
=================

1. Execute the following query on your Oracle database:
CREATE TABLE pdotest (some_num INTEGER DEFAULT 0 NOT NULL);

2. Run the following script:
===============================================================================
<?
$query="SELECT data_default FROM user_tab_columns WHERE table_name='PDOTEST'";
$db = new PDO('oci:dbname=orcl', 'trunk', 'tiger');
$sth = $db->query( $query );
for( $i=0; ( $row = $sth->fetch( PDO::FETCH_ASSOC ) ); $i++ )
    var_dump( $row );
echo "$i rows fetched.\n";
?>
===============================================================================


Expected result:
----------------
No warnings.


Actual result:
--------------
Warning: PDOStatement::fetch(): column 0 data was too large for buffer and was truncated to fit it in /path/to/test.php on
line 7
array(1) {
  ["DATA_DEFAULT"]=>
  string(0) ""
}
1 rows fetched.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-27 18:59 UTC] vs at ez dot no
Note that the query result is wrong. There actually should have been 0 instead of "". This is probably caused by the same problem.
 [2005-10-28 17:02 UTC] tony2001@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 [2011-11-04 15:53 UTC] tomasz at trejderowski dot pl
Sorry, not true. As reported in many similar bug reports (in year 2005 and 2007) and comments to them (in year 2007, 2010 and 2011) this issue is STILL NOT FIXED. Up until end of 2011. At least not for PHP + PDO + Oracle.
 [2012-03-06 17:52 UTC] lucassouza1 at gmail dot com
This issue still happens. I suppose it occurs because for example, an oracle varchar(10) column, is filled with a multibyte char sequence like "maçã", it will overflow the buffer if a charset like 'AL32UTF8' is provided in DSN
 [2012-08-31 14:20 UTC] mouder at mail dot bg
Still happens to me with PDO and Oracle.
 [2013-03-12 19:05 UTC] wilbert dot j at gmail dot com
We found a "solution" to get it work: select cast( tbl.description AS 
varchar2(300) )as desc FROM database.table tbl;
 [2015-01-30 15:38 UTC] glueck at ibou dot net
I fix this problem by this way:
connectionstring: "oci:dbname={$tns};charset=UTF8"
Know the driver will handel UTF8 inside a field correct.
 [2016-03-08 01:35 UTC] sixd@php.net
-Package: PDO related +Package: PDO OCI
 [2017-03-04 03:34 UTC] slavkoss22 at gmail dot com
I have same problem with varchar2(100).
I think we should use E.Rangel's PDOOCI syntax on oci8 driver until PHP PDO extension will be fixed (ever or never).
 [2020-01-14 06:44 UTC] schnettker at gmail dot com
Thanks Wilbert. You made my "decade". After many years i found a good solution. 

varchar2(300) works as a workaround for us
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 13:01:28 2024 UTC