-----Mensaje original-----
De: Keith [mailto:[EMAIL PROTECTED]
Enviado el: Viernes, 16 de Abril de 2004 11:52 a.m.
Para: Tag Libraries Users List
Asunto: Re: More SQL Date problems
Alright. Thanks a lot, everyone! I'll be contacting Oracle Support next week
to see about
getting the issue resolved. :)
Keith
---------- Original Message -----------
From: Justyna Horwat <[EMAIL PROTECTED]>
To: Tag Libraries Users List <[EMAIL PROTECTED]>
Sent: Fri, 16 Apr 2004 11:24:32 -0700
Subject: Re: More SQL Date problems
> Keith,
>
> That's why they have the compatibility tests to avoid the very problem
> that you are seeing with the Oracle driver. This is definitely a bug in
> Oracle's driver implementation that needs to be fixed.
>
> Justyna
>
> Keith wrote:
>
> >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]
------- 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]
