On 3/31/07, Øystein Grøvlen <[EMAIL PROTECTED]> wrote:
Xavier Hanin wrote:
> con.createStatement().executeUpdate("create table Issue ( ID
> char(50) )");
> PreparedStatement st = con.prepareStatement("select count(*)
> from Issue where ? is null");
> st.setNull(1, Types.VARBINARY);
I do not think that CHAR and VARBINARY are compatible types. Try using
Types.VARCHAR instead.
Yes, but why does derby consider the type as CHAR? Is it something from the
specification to assume CHAR when no type can be assumed from the query?
Note that I do not compare to the only column I've created. The column could
have been compatible with VARBINARY.
Indeed in my usecase I can't use VARCHAR because I'm not at the origin of
the query. I use hibernate and do something like this:
from Issue where :status is null or status = :status
Hibernate converts that to something like
select * from Issue where ? is null or status_id = ?
and bind the two parameters with the same value, i.e. the id of the status I
bind in Hibernate, which is a BIGINT, and thus use VARBINARY as sql type for
both parameters binding. And I can't really blame Hibernate, can I?
I've found a (ugly) workaround, so it's not too much an issue for me, but
I'd like to know if there is a specification somewhere defining how type
should be assumed for parameters, saying that VARCHAR should be assumed in
this case (which AFAIU means that only VARCHAR parameters can be checked
with 'is null'). Then I could check with the Hibernate community if there is
a solution to the problem other than my ugly fix.
Any idea?
Xavier
--
Learn Ivy at ApacheCon: http://www.eu.apachecon.com/
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
