Bug #71422 [Csd]: Bogus ORA-01438: value larger than specified precision allowed for this column

Edit report at https://bugs.php.net/bug.php?id=71422&edit=1 ID: 71422 Updated by: sixd@php.net Reported by: alvaro at demogracia dot com Summary: Bogus ORA-01438: value larger than specified precision allowed for this column Status: Closed Type: Bug Package: OCI8 related Operating System: Windows 7 PHP Version: 5.6.17 Assigned To: sixd Block user comment: N Private report: N New Comment: Test out the latest PHP 5.6 code. If all is OK, I will make a new PECL package. Previous Comments: ------------------------------------------------------------------------ [2016-04-14 03:58:28] sixd@php.net Automatic comment on behalf of christopher.jones@oracle.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=8f2e6da8066d4f0b4c3846aeba14f894ef8b02ed Log: Fixed bug #71422 (Fix ORA-01438: value larger than specified precision allowed for this column) ------------------------------------------------------------------------ [2016-04-11 09:04:22] truly dot apito at gmail dot com I'm on 32.bit version of PHP 7.0.5 for Windows, using oci 2.1.0, instant client 11.2 both run/ compile-time. Using the same test script as alvaro, i produced the same error. My OSX 10.11.4/PHP 7.0.4 runs it fine, though. ------------------------------------------------------------------------ [2016-03-02 15:17:22] alvaro at demogracia dot com I've just verified that it works fine up to PHP/5.6.15 (first affected version is 5.6.16) and (as already mentioned) PHP/7.0.x is not affected. I'm using latest Oracle Instant Client release (12.1.0.2.0). My stack is 32-bit. If there's any specific test I can do please feel free to ask. ------------------------------------------------------------------------ [2016-02-09 04:34:25] sixd@php.net This doesn't reproduce on OS X. ------------------------------------------------------------------------ [2016-01-28 09:47:17] alvaro at demogracia dot com I've found more broken stuff. I'd say that using SQLT_INT is in general no longer functional. Switching to SQLT_CHR is not a valid workaround for all situations since certain queries may fail if they expect a number and receive a string. CREATE TABLE TEST ( TEST_ID NUMBER(*,0) NOT NULL, LABEL VARCHAR2(50 CHAR), CONSTRAINT TEST_PK PRIMARY KEY (TEST_ID) ); INSERT INTO TEST (TEST_ID, LABEL) VALUES (1, 'Foo'); COMMIT; SELECT * FROM TEST WHERE TEST_ID=1; <?php $conn = oci_connect('test', 'test', '//hera.mina.s/xe'); // Query returns one row $stmt = oci_parse($conn, 'SELECT LABEL AS RAW_QUERY FROM TEST WHERE TEST_ID=1'); oci_execute($stmt); while ($row = oci_fetch_array($stmt, OCI_ASSOC+OCI_RETURN_NULLS)) { var_dump($row); } // Bind parameters do not return results... $stmt = oci_parse($conn, 'SELECT LABEL AS NUMERIC_BIND_PARAMETER FROM TEST WHERE TEST_ID=:test_id'); $value = 1; oci_bind_by_name($stmt, ':test_id', $value, -1, SQLT_INT); oci_execute($stmt); while ($row = oci_fetch_array($stmt, OCI_ASSOC+OCI_RETURN_NULLS)) { var_dump($row); } // ... unless we stringify them $stmt = oci_parse($conn, 'SELECT LABEL AS STRING_BIND_PARAMETER FROM TEST WHERE TEST_ID=:test_id'); $value = 1; oci_bind_by_name($stmt, ':test_id', $value, -1, SQLT_CHR); oci_execute($stmt); while ($row = oci_fetch_array($stmt, OCI_ASSOC+OCI_RETURN_NULLS)) { var_dump($row); } ------------------------------------------------------------------------ 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 https://bugs.php.net/bug.php?id=71422 -- Edit this bug report at https://bugs.php.net/bug.php?id=71422&edit=1