Re: More SQL Date problems

[Justyna Horwat]

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]