PreparedStatement.setTimestamp does not allo use of DATE index..
603370Oct 15 2007 — edited Oct 15 2007(...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