#41917 [Csd]: oci_field_scale returns expected value multiplied by 256
ID: 41917
User updated by: nobleclem+phpbugs at gmail dot com
Reported By: nobleclem+phpbugs at gmail dot com
Status: Closed
Bug Type: OCI8 related
Operating System: Solaris
PHP Version: 5.2.3
Assigned To: tony2001
New Comment:
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!
Previous Comments:
[2007-07-09 19:02:54] [EMAIL PROTECTED]
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.
[2007-07-06 23:35:47] [EMAIL PROTECTED]
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 1.11.2.6.2.18
+++ 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-06 22:12:51] [EMAIL PROTECTED]
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:
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci06des.htm#sthref949
@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 18:53:11] [EMAIL PROTECTED]
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 18:40:17] nobleclem+phpbugs at gmail dot com
Description:
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:
---
Assumptions:
- field #2 is of type NUMBER(12,2)
- all_tab_columns.data_precision is 12
- all_tab_columns.data_scale value is 2
Code:
$conn = oci_connect('username', 'password');
$stmt = oci_parse($conn, SELECT * FROM fees);
oci_execute($stmt);
$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.
--
Edit this bug report at http://bugs.php.net/?id=41917edit=1
#41917 [Csd]: oci_field_scale returns expected value multiplied by 256
ID: 41917 User updated by: nobleclem+phpbugs at gmail dot com Reported By: nobleclem+phpbugs at gmail dot com Status: Closed Bug Type: OCI8 related Operating System: Solaris PHP Version: 5.2.3 Assigned To: tony2001 New Comment: 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! Previous Comments: [2007-09-07 15:05:26] 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-07-09 19:02:54] [EMAIL PROTECTED] 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. [2007-07-06 23:35:47] [EMAIL PROTECTED] 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 1.11.2.6.2.18 +++ 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-06 22:12:51] [EMAIL PROTECTED] 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: http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci06des.htm#sthref949 @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 18:53:11] [EMAIL PROTECTED] 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. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/41917 -- Edit this bug report at http://bugs.php.net/?id=41917edit=1
#41917 [NEW]: oci_field_scale returns expected value multiplied by 256
From: nobleclem+phpbugs at gmail dot com
Operating system: Solaris
PHP version: 5.2.3
PHP Bug Type: OCI8 related
Bug description: oci_field_scale returns expected value multiplied by 256
Description:
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:
---
Assumptions:
- field #2 is of type NUMBER(12,2)
- all_tab_columns.data_precision is 12
- all_tab_columns.data_scale value is 2
Code:
$conn = oci_connect('username', 'password');
$stmt = oci_parse($conn, SELECT * FROM fees);
oci_execute($stmt);
$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.
--
Edit bug report at http://bugs.php.net/?id=41917edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41917r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41917r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41917r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41917r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41917r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41917r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41917r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41917r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41917r=support
Expected behavior:http://bugs.php.net/fix.php?id=41917r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41917r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41917r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41917r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41917r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41917r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41917r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41917r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41917r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41917r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41917r=mysqlcfg
