Xavier Hanin wrote:
On 3/31/07, *Øystein Grøvlen* <[EMAIL PROTECTED]
<mailto:[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.
Ah, I see. My mistake. Then I do not see a reason why this should not
be allowed. Which version of Derby are you using? There have been some
fixes in this area lately (see DERBY-1610), and I will try your test
case on the development trunk later today.
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?
Why not? :-)
I would blame Hibernate for using VARBINARY when it should use BIGINT,
but I guess that is not the issue here.
--
Øystein
