php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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 Developer Edit
 [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

Pull Requests

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-2025 The PHP Group
All rights reserved. 		Last updated: Tue Nov 04 05:00:01 2025 UTC