remove my mail from your list
-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- /
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]
please remove my mail from your list fchauvel@terra.com.pe
-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- /
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]
