Thanks for the reminder. I have submitted this patch. I am wondering if
previously failing test cases should be added to Network server tests.
Satheesh
Sending java\drda\org\apache\derby\impl\drda\DRDAConnThread.java
Transmitting file data .
Committed revision 158935.
Army wrote:
Committers,
I submitted this rather simple patch three weeks ago, but it looks like
it fell through the cracks. I'm re-attaching a
newly created version of the patch (against the most recent codeline).
This is a fix for DERBY-157. I ran the derbynetmats suite with these
changes and there were no failures. As all changes in this patch are
specific to the Network Server, I don't think any other tests need to
be run.
Could someone please commit?
Thanks,
Army
-------- Original Message --------
Subject: [PATCH] Derby-157 Patch, plus 2 other minor server fixes.
Date: Thu, 03 Mar 2005 16:05:09 -0800
From: Army <[EMAIL PROTECTED]>
Reply-To: Derby Development <[email protected]>
To: Derby Development <[email protected]>
Attached is a patch that does the following three (pretty minor)
things:
1) First and foremost, it resolves DERBY-157. If a datetime string
that is not recognized by the server is received
from the client, the server will now catch the resultant Java exception
and throw a valid SQLException with SQLSTATE
22007 ("The syntax of the string representation of a datetime value is
incorrect"). The old behavior was to throw a
DRDA protocol exception and deallocate the connection.
2) It corrects a small problem in the way the server treats timestamp
strings. This problem, like DERBY-157, only
happens with non-JCC clients: users who insert a timestamp value into a
Derby table by binding a _string_ value (ex.
"1948-04-08 02:24:48") to a _timestamp_ parameter will actually get a
different value back when they do a SELECT because
the value is 'warped' by the server before insertion. In particular,
extra 0's are added to the end of the string--ex.
"1948-04-08 02:24:48000"--which are then treated as seconds when the
server calls java.sql.Timestamp.valueOf(), and thus
the wrong value is inserted.
This doesn't happen with JDBC drivers because the code in question is
only executed when a _string_ value is being bound
to a _Timestamp_ parameter--basically, the user would have to do
something like
ps.setTimestamp(1, "1948-04-08 02:24:48")
--but JDBC doesn't allow that, because the second argument has to be a
Timestamp object. With an ODBC client, though,
this kind of thing is possible, and so this problem should be fixed.
3) It removes an extraneous call to "finalizeChain()" that was
introduced as part of the "Multiple EXCSAT fix" patch
(see
http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200501.mbox/[EMAIL PROTECTED]).
This
extra call doesn't lead to any bad behavior, but since it is
unnecessary and technically incorrect, it's good to remove
it. It's a simple one-line removal, so if no one minds, I figure it
can be made with this patch, since all of the
changes in this patch are to the same file and they are all pretty
minor.
In terms of tests, I haven't modified or added any test cases because
these are problems that can only be seen with a
non-Java driver--and as far as I know, the current Derby test harness
has no means of introducing such a driver.
I have run the derbynetmats suite (on Windows using jdk142) with these
very minor changes and all tests passed.
Committers, please commit when you can...
Thanks,
Army
Index: java/drda/org/apache/derby/impl/drda/DRDAConnThread.java
===================================================================
--- java/drda/org/apache/derby/impl/drda/DRDAConnThread.java (revision 158925)
+++ java/drda/org/apache/derby/impl/drda/DRDAConnThread.java (working copy)
@@ -806,7 +806,6 @@
case CodePoint.EXCSAT:
parseEXCSAT();
writeEXCSATRD();
- finalizeChain();
break;
case CodePoint.ACCSEC:
int securityCheckCode = parseACCSEC();
@@ -4039,7 +4038,17 @@
String paramVal = reader.readStringData(10).trim(); //parameter may be char value
if (SanityManager.DEBUG)
trace("ndate parameter value is: \""+paramVal+"\"");
- ps.setDate(i+1, java.sql.Date.valueOf(paramVal));
+ try {
+ ps.setDate(i+1, java.sql.Date.valueOf(paramVal));
+ } catch (java.lang.IllegalArgumentException e) {
+ // Just use SQLSTATE as message since, if user wants to
+ // retrieve it, the message will be looked up by the
+ // sqlcamessage() proc, which will get the localized
+ // message based on SQLSTATE, and will ignore the
+ // the message we use here...
+ throw new SQLException(SQLState.LANG_DATE_SYNTAX_EXCEPTION,
+ SQLState.LANG_DATE_SYNTAX_EXCEPTION.substring(0,5));
+ }
break;
}
case FdocaConstants.DRDA_TYPE_NTIME:
@@ -4047,20 +4056,37 @@
String paramVal = reader.readStringData(8).trim(); //parameter may be char value
if (SanityManager.DEBUG)
trace("ntime parameter value is: "+paramVal);
- ps.setTime(i+1, java.sql.Time.valueOf(paramVal));
+ try {
+ ps.setTime(i+1, java.sql.Time.valueOf(paramVal));
+ } catch (java.lang.IllegalArgumentException e) {
+ throw new SQLException(SQLState.LANG_DATE_SYNTAX_EXCEPTION,
+ SQLState.LANG_DATE_SYNTAX_EXCEPTION.substring(0,5));
+ }
break;
}
case FdocaConstants.DRDA_TYPE_NTIMESTAMP:
{
- // DB2 represents ts with 26 chars, and a slightly different format than Java standard
- // we do the conversion and pad 3 digits for nano seconds.
+ // JCC represents ts in a slightly different format than Java standard, so
+ // we do the conversion to Java standard here.
String paramVal = reader.readStringData(26).trim(); //parameter may be char value
if (SanityManager.DEBUG)
trace("ntimestamp parameter value is: "+paramVal);
- String tsString = paramVal.substring(0,10)+" "+paramVal.substring(11,19).replace('.', ':')+paramVal.substring(19)+"000";
- if (SanityManager.DEBUG)
- trace("tsString is: "+tsString);
- ps.setTimestamp(i+1, java.sql.Timestamp.valueOf(tsString));
+ try {
+ String tsString = paramVal.substring(0,10) + " " +
+ paramVal.substring(11,19).replace('.', ':') +
+ paramVal.substring(19);
+ if (SanityManager.DEBUG)
+ trace("tsString is: "+tsString);
+ ps.setTimestamp(i+1, java.sql.Timestamp.valueOf(tsString));
+ } catch (java.lang.IllegalArgumentException e1) {
+ // thrown by Timestamp.valueOf(...) for bad syntax...
+ throw new SQLException(SQLState.LANG_DATE_SYNTAX_EXCEPTION,
+ SQLState.LANG_DATE_SYNTAX_EXCEPTION.substring(0,5));
+ } catch (java.lang.StringIndexOutOfBoundsException e2) {
+ // can be thrown by substring(...) if syntax is invalid...
+ throw new SQLException(SQLState.LANG_DATE_SYNTAX_EXCEPTION,
+ SQLState.LANG_DATE_SYNTAX_EXCEPTION.substring(0,5));
+ }
break;
}
case FdocaConstants.DRDA_TYPE_NCHAR:
|
