PreparedStatement.setTimestamp does not allo use of DATE index..

Question

(...although they' re not suposed be related)
Hi;
I use Oracle 10g with Java JDBC driver ojdbc14.jar and I have a PreparedStatement on which among other "bind" JDBC parameters I have a java.util.Date. The ORM that we use (Hibernate 2.0.3) passes this Date instance as a java.sql.Timestamp binding it with setTimestamp on the PreparedStatement.
Interestingly enaugh, this way of binding the value does not make the database use the date column index, although the explain available from TOAD / Session browse, for instance, tells me the planner first demands an index scan there (it is possible i think that explain only operates on prepared SQL alone, disregarding value initial types and values). Doing a preparedStatement.setDate(value) instead, passing a java.sql.Date, uses the index and probably fully respects the Explain Plan that I have seen.
I assure you I have done many tests, with exact same query, parameter types and values, session origination and environment and changing one thing at a time. The only thing that being changed enables the query to make use of the DATE column index and return under a second, compared to tens of seconds of full table scan with expensive function calls, is to replace the preparedStatement.setTimestamp with setDate.
This can only be a JDBC bug, as far as I can tell. Do you know of this problem? What may be the cause?
As a note, since I need to continue to use that version of Hibernate on that spot, I momentarily worked around this apparent bug by modifying the SQL WHERE clause in order to provide the DATE value as to_date function output from a String bind, so doing date_col = to_date('YYYY-MM-DD', :value) instead of date_col = :value. Works fain, but just a work around.
Looking forward for your answer and suggestions,
Nicu Marasoiu

Answer 1

A few remarks:
- Toad explain plans can be frought by implicit data type conversions.
Generally speaking everything is treated as a varchar2.
- You would need to show the plan from v$sql_plan.
- It would be a JDBC bug if you can show 'correct' behavior from sql*plus, making sure you actually do use bind variables of the correct type (so VARIABLE foo date prior to running the SQL, the SELECT referencing :foo)
- In the past I have observed strange CBO behavior because the date wasn't a complete date (ie time was missing). This can be rectified by function based indexes.
- You probably can enable event 10053 in your JDBC session, or event 10046 level 12
Sybrand Bakker
Senior Oracle DBA