-----Mensaje original-----
De: Jonathan Bruce [mailto:[EMAIL PROTECTED]
Enviado el: Viernes, 16 de Abril de 2004 01:52 p.m.
Para: Tag Libraries Users List
CC: Pierre Delisle; Lance Andersen
Asunto: Re: More SQL Date problems
Justyna,
This is also a secret/poorly documented property in the Oracle-thin
driver that you can set to force the driver to operate in a CTS
compliant mode. Lance - can you remember the exact property ?
-Jonathan
Justyna Horwat wrote:
> 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]
>
---------------------------------------------------------------------
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]
