php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #57049 Overflow when fetching data from Double field in DB2/UDB/Cloudscape
Submitted: 2006-05-30 04:22 UTC Modified: 2006-10-10 23:11 UTC
From: royb at ubiquity dot com dot au Assigned: wez (profile)
Status: Closed Package: PDO_ODBC (PECL)
PHP Version: 5.1.2 OS: XP IIS 5.1
Private report: No CVE-ID: None
 [2006-05-30 04:22 UTC] royb at ubiquity dot com dot au
Description:
------------
Installed Windows 5.1.4 on discovering error but made no difference.

hence using 

php_pdo_odbc.dll version 5.1.4.4

Tried against the following databases
UDB2 version 8.1
DB2(zOS) Version 8
Cloudscape version 10.1

All failed

Unless the DOUBLE field contains a NULL then OK.

Note replacing PDO with db2_connect does not generate the error.

Reproduce code:
---------------
Create table tableA

CREATE TABLE APP.tableA(
  NAME CHAR(30) NOT NULL, 
  fldA DOUBLE,
  fldB INTEGER,
  PRIMARY KEY(name) );

Insert a row:

insert into APP.tableA
(NAME,fldA ,fldB ) Values('Baz',3,2000); 

Execute a select statement like
   'Select fldA, fldB from APP.tableA'

Where field fldA is created as a DOUBLE and fldB is an INTEGER.

or 

Cast any valid field to a DOUBLE seems to generate the error.


'Select CAST(fldB as DOUBLE) as testfld from tableA'





example code:

try {
     $dbh = new PDO($constrng, $user, $pass);
     echo 'Connected';

    } catch (PDOexception $exp) {
    echo 'Exception: ' . $exp->getMessage();
    }
	
    $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
		
	
   $sql = "Select fldA, fldB from APP.tableA;";	
	
   $sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR,PDO::CURSOR_FWDONLY));
	
   $sth->execute();
   print "results for $sql \n\n";
   $rows = $sth->fetchAll();
   print_r($rows);	
	
	
	


Actual result:
--------------
Returns the following error message.


SQLSTATE[22003]: Numeric value out of range: -99999 [IBM][CLI Driver] CLI0111E Numeric value out of range. SQLSTATE=22003 (SQLFetchScroll[-99999] at ext\pdo_odbc\odbc_stmt.c:372)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-07-28 11:42 UTC] simonslaws at googlemail dot com
I am getting this also in 5.1.4 on windows XP. It is the root cause of SDO error 7880 (http://pecl.php.net/bugs/bug.php?id=7880). 

I think the problem is down in the odbc_stmt.c::odbc_stmt_describe() function. SQLDescribeCol is used to get the column size. SQLDescribeCol though returns the column precision. More characters are required to store a float, double etc. than indicated by precision as, in character form, they have the E+000 bit on the end. I made the following change to fix it in my checked out code. (+ = new lines). I have only tried this on windows and only against DB2. B.t.w. sorry for the stupid question but is there a way I can attach a patch to a bug report rather than inline it?


static int odbc_stmt_describe(pdo_stmt_t *stmt, int colno TSRMLS_DC)
{
	pdo_odbc_stmt *S = (pdo_odbc_stmt*)stmt->driver_data;
	struct pdo_column_data *col = &stmt->columns[colno];
	zend_bool dyn = FALSE;
	RETCODE rc;
	SWORD	colnamelen;
	SDWORD	colsize;

	rc = SQLDescribeCol(S->stmt, colno+1, S->cols[colno].colname,
			sizeof(S->cols[colno].colname)-1, &colnamelen,
			&S->cols[colno].coltype, &colsize, NULL, NULL);

	if (rc != SQL_SUCCESS) {
		pdo_odbc_stmt_error("SQLBindCol");
		return 0;
	}

+	// The colsize that is returned above is actually the column precision.
+	// For a floating point number this does not represent how many
+	// bytes are required to store it in a char array as you need
+	// to store the E+000 bit as well.
+	rc = SQLColAttribute(S->stmt,
+                         colno+1,
+                         SQL_DESC_DISPLAY_SIZE,
+                         NULL,
+                         0,
+                         NULL,
+                         &colsize);
+
+	if (rc != SQL_SUCCESS) {
+		pdo_odbc_stmt_error("SQLBindCol");
+		return 0;
+	}
 [2006-10-10 23:11 UTC] wez@php.net
This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.

Thanks for the patch!
Fix will be in PHP 5.2
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 22 06:01:30 2024 UTC