On 3/31/07, Øystein Grøvlen <[EMAIL PROTECTED]> wrote:
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?
I'm using version 10.2.2.0. 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.
Ok, thanks a lot.
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 didn't mean that I can never blame hibernate, but in this case I don't see how they could use another sql type. I would blame Hibernate for using VARBINARY when it should use BIGINT,
but I guess that is not the issue here.
Agreed. Thanks for your time. - Xavier -- Learn Ivy at ApacheCon: http://www.eu.apachecon.com/ Manage your dependencies with Ivy! http://incubator.apache.org/ivy/
