db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@sbcglobal.net>
Subject [Fwd: [PATCH] Derby-157 Patch, plus 2 other minor server fixes.]
Date Thu, 24 Mar 2005 18:10:25 GMT

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?


-------- Original Message --------
Subject: [PATCH]  Derby-157 Patch, plus 2 other minor server fixes.
Date: Thu, 03 Mar 2005 16:05:09 -0800
From: Army <qozinx@sbcglobal.net>
Reply-To: Derby Development <derby-dev@db.apache.org>
To: Derby Development <derby-dev@db.apache.org>

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/%3c41EF3DC3.6030407@Sourcery.Org%3e).
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...


View raw message