-----Mensaje original-----
De: Keith [mailto:[EMAIL PROTECTED]
Enviado el: Viernes, 16 de Abril de 2004 09:25 a.m.
Para: Tag Libraries Users List
Asunto: Re: More SQL Date problems
So this is something in the Oracle JDBC driver that needs to be fixed? Just
wondering
whether I have to watch for a new JDBC driver or the next JSTL update to
solve the
problem.
Right now I'm using a workaround similar to what Hans showed me and things
are working
fine. Just may be confusing for whoever may take over for me in the future
if they don't
know about the problem.
Thanks!
Keith
---------- Original Message -----------
From: Justyna Horwat <[EMAIL PROTECTED]>
To: Tag Libraries Users List <[EMAIL PROTECTED]>
Sent: Fri, 16 Apr 2004 09:54:13 -0700
Subject: Re: More SQL Date problems
> Hans,
>
> I looked into the SQL problem and consulted with the JDBC specification
> lead, Jonathan Bruce. Jonathan said that what JSTL is doing is correct:
> when setObject(index, null) is passed in a null value this should be
> converted by the driver to an SQL null.
>
> 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.
>
> Thanks,
>
> Justyna
>
> Hans Bergsten wrote:
>
> > Wolfgang Röckelein wrote:
> >
> >> Hi,
> >>
> >> at JDBC level there are two different possibilities to set a
> >> parameter value to null: with setNull and setting to null. Depending
> >> on the driver sometimes only on of these methods work, and when it
> >> does not work, you see the "java.sql.SQLException: Invalid column
> >> type" error you see.
> >>
> >> I think this was already changed or discussed sometime during the
> >> standard taglib development.
> >
> >
> > Right. I was looking at the code for JSTL in the CVS archive, and it
> > calls setObject(index, null) when passed a null value, and there's a
> > comment that this should be converted by the driver to an SQL null.
> > Browsing through the JDBC JavaDocs and the JDBC spec, there seems to
> > be some support for this claim, but it's not 100% clear. It's possible
> > that the driver Keith is using doesn't handle it, and maybe it would
> > be better if JSTL used setNull(). The reason it doesn't is that it
> > would required additional type info for the <sql:param> case.
> >
> > Pierre, this may be something to look at again for JSTL.next.
> >
> > Keith, a work-around for this would be:
> >
> > <fmt:parseDate value="${param.dob}" var="parsed_dob"
> > pattern="dd-MM-yyyy" />
> >
> > <c:choose>
> > <c:when test="${!empty parsed_dob}">
> > <sql:update>
> > INSERT INTO resource_registry (resource_id, dob)
> > VALUES (res_id_seq.NEXTVAL, ? )
> > <sql:dateParam value="${parsed_dob}" type="date"/>
> > </sql:update>
> > </c:when>
> > <c:otherwise>
> > INSERT INTO resource_registry (resource_id)
> > VALUES (res_id_seq.NEXTVAL)
> > </sql:update>
> > </c:otherwise>
> > </c:choose>
> >
> > If the real case involves many parameters that may be null, this
> > gets ugly, but if it's just this one, it may be okay.
> >
> > Hans
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
------- End of Original Message -------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
