|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #41917 oci_field_scale returns expected value multiplied by 256
Submitted: 2007-07-06 18:40 UTC Modified: 2007-09-07 15:06 UTC
From: nobleclem+phpbugs at gmail dot com Assigned: tony2001 (profile)
Status: Closed Package: OCI8 related
PHP Version: 5.2.3 OS: Solaris
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.
Block user comment
Status: Assign to:
Bug Type:
From: nobleclem+phpbugs at gmail dot com
New email:
PHP Version: OS:


 [2007-07-06 18:40 UTC] nobleclem+phpbugs at gmail dot com
When using oci_field_scale to obtain the value stored in all_tab_columns.data_scale in oracle for a field the value returned is that in all_tab_columns.data_scale multiplied by 256.

Reproduce code:
- field #2 is of type NUMBER(12,2)
- all_tab_columns.data_precision is 12
- all_tab_columns.data_scale value is 2

$conn = oci_connect('username', 'password');
$stmt = oci_parse($conn, "SELECT * FROM fees");
$field_number = 2;

$scale = oci_field_scale( $stmt, $field_number );

Expected result:
$scale should be assigned the value of 2.

Actual result:
$scale is assigned the value of 512.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2007-07-06 18:53 UTC]
PHP/OCI8 returns exactly what it got from OCIAttrGet(.., OCI_DTYPE_PARAM, .., .., OCI_ATTR_SCALE, ).
If Oracle Client returns wrong information, we can't change or fix that.
 [2007-07-06 22:12 UTC]
Although I can't reproduce the given testcase on Linux there is a bug here that stops other testcases working for me, and may cause a port specific difference in behavior for nobleclem's testcase.

The datatypes of the scale and precision fields in php_oci_out_column (php_oci8_int.h) should be sb1 and s2 respectively. At the moment they are both ub2.  This, for example, prevents the scale for a FLOAT column being displayed as -127.  

See table 6.8 in Oracle's OCI manual:

@nobleclem, the scale and precision values returned by the OCI8 extension and Oracle's OCI library are the programmatic definitions of scale and precision, which are different to the user-level values given in the all_tab_columns table.

@tony2001, I will commit a new testcase to PHP5 and 6, but will let you evaluate and merge the datatype fix.
 [2007-07-06 23:35 UTC]
A new test has been merged and old tests updated.  They will cause diffs until Tony merges the code change.

The suggested fix is:
--- php_oci8_int.h	29 Mar 2007 02:33:03 -0700
+++ php_oci8_int.h	06 Jul 2007 15:53:44 -0700	
@@ -215,8 +215,8 @@
 	php_oci_define *define;			/* define handle */
 	int piecewise;					/* column is fetched piece-by-piece */
 	ub4 cb_retlen;					/* */
-	ub2 scale;						/* column scale */
-	ub2 precision;					/* column precision */
+	sb1 scale;						/* column scale */
+	sb2 precision;					/* column precision */
 	ub1 charset_form;				/* charset form, required for NCLOBs */
 	ub2 charset_id;					/* charset ID */
 } php_oci_out_column; /* }}} */

 [2007-07-09 19:02 UTC]
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
Thank you for the report, and for helping us make PHP better.

 [2007-09-07 15:05 UTC] nobleclem+phpbugs at gmail dot com
Tested 5.2.4 and the ub# to sb# has resolved the problem and oci_field_precision() is not returning the correct value.

Thank You for your hard work!
 [2007-09-07 15:06 UTC] nobleclem+phpbugs at gmail dot com
Typo in previous comment it should read:

Tested 5.2.4 and the ub# to sb# has resolved the problem and
oci_field_precision() is NOW returning the correct value.

Thank You for your hard work!
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Oct 04 04:05:53 2022 UTC