#18758 [NEW]: OCI8 ext not handling Oracle 9i TIMESTAMP datatypes

From: robert@ud.com Operating system: RH Linux 7.2 PHP version: 4.2.1 PHP Bug Type: OCI8 related Bug description: OCI8 ext not handling Oracle 9i TIMESTAMP datatypes PHP 4.2.1 compiled using --with-oci8 option (9i client libs), connecting/querying a remote Oracle 9i database server. Test query simply returns the current timestamp from the database server using the native Oracle 9i TIMESTAMP and/or TIMESTAMP WITH TIME ZONE datatypes. (reference: http://otn.oracle.com/docs/products/oracle9i/doc_library/release2/server.920/a96540/sql_elements2a.htm#47732) However, the PHP/OCI8 extension does not know what to do with that datatype and appears to treat it as unknown, thus the query result shows up blank in the output. Details: ------------------ This PHP code: ############## $objDBCN = OCILogon("uid","pwd","sid"); $objSTH = OCIParse($objDBCN, "SELECT CURRENT_TIMESTAMP FROM DUAL"); OCIExecute($objSTH); %> <pre style="font-family:verdana;font-size:8.5pt"> <% OCIFetchStatement($objSTH, $objRS); echo "Column Data Type: " . OCIColumnType($objSTH, 1). "\r\n"; print_r($objRS); %> </pre> <% OCIFreeStatement($objSTH); OCILogOff($objDBCN); ########### returns this blank/unknown output: *********************** Column Data Type: 188 Array ( [CURRENT_TIMESTAMP] => Array ( [0] => ) ) *********************** ...but this PHP code (casting the timestamp datatype as a CHAR): ############## $objDBCN = OCILogon("uid","pwd","sid"); $objSTH = OCIParse($objDBCN, "SELECT TO_CHAR(CURRENT_TIMESTAMP) FROM DUAL"); OCIExecute($objSTH); %> <pre style="font-family:verdana;font-size:8.5pt"> <% OCIFetchStatement($objSTH, $objRS); echo "Column Data Type: " . OCIColumnType($objSTH, 1). "\r\n"; print_r($objRS); %> </pre> <% OCIFreeStatement($objSTH); OCILogOff($objDBCN); ########### returns good/valid output: **************** Column Data Type: VARCHAR Array ( [TO_CHAR(CURRENT_TIMESTAMP)] => Array ( [0] => 06-AUG-02 04.43.41.230000 PM +00:00 ) ) **************** Note: The datatype in the second query is correctly found as "VARCHAR", but the first reports just an integer (which means that the PHP/OCI8 code was not able to translate the "188" into something it knows about. (187 = TIMESTAMP, 188 = TIMESTAMP WITH TIME ZONE). Obviously, I can work around this problem by casting all TIMESTAMP datatypes to CHAR in my Oracle SQL statements, but the reality is that our applications use functions/"stored procs" that are shared by C code _and_ PHP, and hacking away from the native supported datatypes is not very efficient. It would be nice if the PHP/OCI8 extension could be updated to handle the TIMESTAMP datatype just as it is able to handle the DATE datatype today. -- Edit bug report at http://bugs.php.net/?id=18758&edit=1 -- Fixed in CVS: http://bugs.php.net/fix.php?id=18758&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=18758&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=18758&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=18758&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=18758&r=support Expected behavior: http://bugs.php.net/fix.php?id=18758&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=18758&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=18758&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=18758&r=globals