php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #42284 Invalid data retrieved from numeric columns
Submitted: 2007-08-13 13:43 UTC Modified: 2007-11-08 19:44 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:2 (66.7%)
From: milan dot babuskov at gmail dot com Assigned:
Status: Closed Package: InterBase related
PHP Version: 5.2.4RC1 OS: Slackware Linux 12.0
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: milan dot babuskov at gmail dot com
New email:
PHP Version: OS:

 

 [2007-08-13 13:43 UTC] milan dot babuskov at gmail dot com
Description:
------------
PHP does not extract the values in NUMERIC(18,7) and NUMERIC(18,8) columns correctly.

Reproduce code:
---------------
create table test ( d1 numeric(18,7), d2 numeric(18,8));
insert into test (d1,d2) values (6543210.1234567, 87654321.01234567);
commit;

<?
 ibase_connect('localhost:mydb','sysdba', 'aa');

 $res = ibase_query('select d5, d6 from test');
 $row = ibase_fetch_row($res);
 echo "D5 = ".$row[0].",\n";
 echo "D6 = ".$row[1]."\n";
?>



Expected result:
----------------
D5 = 6543210.1234567,
D6 = 87654321.01234567

Actual result:
--------------
D5 = 654321.1234567,
D6 = 8765432.101234567

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-08-13 13:44 UTC] milan dot babuskov at gmail dot com
Fields D5 and D6 should be D1 and D2. Sorry for the confusion.
 [2007-08-16 13:40 UTC] milan dot babuskov at gmail dot com
It works properly with PHP 4.x versions. The problem is in function _php_ibase_var_zval, in the SQL_INT64 branch of the 'case' statement. If I take the same part from PHP 4.4.0 and copy it there, everything works properly (I also needed to add ISC_INT64_FORMAT define which was missing).

Please note that 5.x code works properly with NUMERIC(18,5) for example. But it fails for NUMERIC(18,7) and 18,8. I didn't test other types, but I assume if fails for any precision greater than 6. PHP 4.x code works properly in all cases.
 [2007-10-21 16:11 UTC] ilpochta at gmail dot com
Duplicate of the http://bugs.php.net/39700

This bug is dangerous, because you may get incorrect result when you multiply fields with smaller precision. 

E.g. for international shop:
--------
CREATE TABLE goods (id INTEGER, price NUMERIC(10,4));
CREATE TABLE currency (code CHAR(3), exchange_rate NUMERIC(10,4));
SELECT goods.id, goods.price*currency.exchange_rate AS local_price
 FROM goods, currency WHERE currency.code='EUR'
--------
...and you lucky customers have goods for 1/10 of price :(
 [2007-11-08 19:44 UTC] lwe@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.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 13:01:31 2024 UTC