Re: Fwd: Cannot pass null in Parameter in Query for ISNULL

This might be interesting (meanwhile the Microsoft, Oracle and Derby
drivers have been fixed).

If I read this correctly, then postgresql needs to be tested as
follows (quote) until compatible:

"This behavior is in fact enforced as part of the J2EE compatibility
in the CTS. The JDBC Driver Test Suite is publicly accessible and can
be used to weed out the JDBC drivers that are not compatible."

Here is the link for the discussion that resulted in a fix for derby:

https://issues.apache.org/jira/browse/DERBY-1938?focusedCommentId=12441025&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12441025

Quote starts:

Dag H. Wanvik added a comment - 10/Oct/06 00:47
I googled and found a discussion on this on the mailinglist
for the Jakarta taglibs project:

http://www.mail-archive.com/taglibs-user(at)jakarta(dot)apache(dot)org/msg07198.html

This thread (dated; 2004) seems to indicate that at least the jTDS
driver for SQL server
accepts this usage.

Digging more, the next link says that the behavior is sanctioned an in
deed checked
by the J2EE CTS (the person claims to have consulted former spec lead
Jonathan Bruce):

http://www.mail-archive.com/taglibs-user(at)jakarta(dot)apache(dot)org/msg06987.html

This is a link to mail by Lance, indicating the Oracle can also accept
this in a
"CTS compatibility mode":

http://www.mail-archive.com/taglibs-user(at)jakarta(dot)apache(dot)org/msg06997.html

The JDBC Tutorial books says "no", the 4.0 API says "OK, but not
guaranteed portable".
The API is more authoritative than the book, according to Lance.

Given the above, and that the API is more authoritative than the book,
I think it would
perhaps be OK for Derby to support this in the interest of ease of
portability of apps to
Derby.

Not my itch, though :)

Quote ends

Kind Regards,

Bernard

On Sat, 12 May 2012 11:06:21 -0400, you wrote:

>Bernard <bht237(at)gmail(dot)com> writes:
>> May I ask for suggestions for a way forward towards a solution?
>
>The long and the short of this is that your application, which
>presumably knows what it might pass for this parameter, has to provide
>that type information (by means of using the appropriate setXXX call).
>If the server's parser tries to guess a type, that will simply move the
>pain from this case to other cases, namely those where the choice really
>matters and it guesses wrong. Similarly, the JDBC driver doesn't have
>enough information to make a correct guess.
>
>Having said that, it's interesting to wonder how much would break if
>setObject were to arbitrarily assume the data type is TEXT. The
>response to anybody complaining would be more or less what I'm saying
>to you, which is "don't use setObject if you don't like the results".
>Again, this would only be shifting the pain from some cases to others,
>but I wonder whether there would be more or fewer pain cases.
>
> regards, tom lane