You also need to modify your init.ora to include compatible=9.0.0.0.0
This works great with the Oracle ojdbc.jar
or the classes12dms.jar and dms2Server.jar (part of o4j)
regards lance
Jonathan Bruce wrote:
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]
