There is a serious problem with GemConnect reads/writes to Oracle
TIMESTAMP fields containing a fractional second component (Oracle data
fields defined as TIMESTAMP(X), where X > 0). The current implementation
incorrectly scales the fractional second component when translating it
to milliseconds for the GemStone DateTime object.
When reading the Oracle TIMESTAMP(X) field into GemStone, this can result
in the millisecond value being too large, overflowing into the
seconds/minutes/hours fields and resulting in the generation of a
GemStone DateTime object that is incorrect. In some cases, the excessively
large millisecond value will break the GCI call generating the DateTime,
resulting in a GS #objErrDoesNotExist error. The possible variance from
the correct time is proportional to the scale of the fractional second
specification for the TIMESTAMP field:
TIMESTAMP(X) Worst-case variation
X = ? from correct time
------------ --------------------
1 28 hours
2 2.8 hours
3 17 minutes
4 1.7 minutes
5 10 seconds
6 1 second (Note: TIMESTAMP(6) is the Oracle default)
7 0.1 seconds
8 0.01 seconds
9 correct
When writing from GemStone to Oracle, the conversion of the GemStone
DateTime millisecond field to the TIMESTAMP fractional seconds field will
result in a fractional second value that is too small, but the other fields in
the TIMESTAMP will be correct. The worst-case variation will be < 1 second.
Note that if the Oracle TIMESTAMP field is *only* generated by GemStone,
and is *only* read back by GemStone, that the DateTime write/read results
will be consistent, as the incorrect conversions will cancel each other out.
The TIMESTAMP as stored in Oracle will be incorrect, but GemStone will
see a consistent DateTime value between write and read. Only the TIMESTAMP
fractional second field is incorrect in this case.
Customers affected by this problem should upgrade to the upcoming
GemConnect 2.2.1 release, which will specifically address this problem.
The release notes will include instructions on how to fix Oracle
TIMESTAMP fields that were written by earlier versions of GemConnect.
No workaround
Last updated: 4/29/09