php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #18758 OCI8 ext not handling Oracle 9i TIMESTAMP datatypes
Submitted: 2002-08-06 12:49 UTC Modified: 2002-10-17 03:08 UTC
From: robert at ud dot com Assigned:
Status: Closed Package: OCI8 related
PHP Version: 4.2.1 OS: RH Linux 7.2
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: robert at ud dot com
New email:
PHP Version: OS:

 

 [2002-08-06 12:49 UTC] robert at ud dot com
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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-08-13 10:54 UTC] kalowsky@php.net
I think some of this has been delt with in the non stable CVS versions.  can you try one please and confirm or deny this?
 [2002-08-13 23:01 UTC] robert at ud dot com
Unfortunately, this work I am doing on this is for an enterprise level software product and I cannot justify the time right now to troubleshoot and test against a non-stable CVS build of PHP.  Maybe soon (week).  I'll have to come back to this problem.
 [2002-08-21 19:16 UTC] robert at ud dot com
Finally got around to trying it out.
No go.

Problem (unhandled Oracle 9i TIMESTAMP datatype) remains using the latest CVS build (4.3.0-dev), as of today. (from snaps.php.net).
 [2002-10-17 03:08 UTC] thies@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 11:01:27 2024 UTC