I had a similar problem with Timestamps and the MySQL driver. We fixed it
using the char type on the sql element to format the timestamp:
<sql name="changeDate" type="char[yyyyMMddhhmmss]"/>
This solution worked or us, you might be able to get away with the same.
Ryan-
On 9/30/02 10:37 AM, "Bruce Snyder" <[EMAIL PROTECTED]> wrote:
> This one time, at band camp, Brian Nivens said:
>
> BN>Could you describe the problem with Oracle timestamps? We are having
> trouble
> BN>with a timestamp field that we were hoping to use to prevent concurrency.
> BN>The ObjecModifiedException goes away when we put dirty="ignore" in the sql
> BN>field.
> BN>
> BN>Perhaps I could help by giving the Oracle timestamp a tolerance?
> ...
> BN>What database are you using? The reason I ask is that there is a problem
> BN>with
> BN>either Oracle or the Oracle JDBC drivers and the way timestamps are
> handled.
> BN>The trouble is with handling of the nanoseconds. This is what could cause
> BN>the
> BN>date fields to be off resulting in the ObjecModifiedException.
>
> Brian,
>
> This problem has to do with the way a java.sql.Timestamp is stored in Oracle.
> I just inserted one into Oracle and here is what SQL*Plus shows me:
>
> 23-OCT-02 10.34.26.000000 AM
>
> Notice the milliseconds are gone!
>
> When using an oracle.sql.TIMESTAMP, the milliseconds are preserved. At
> first glance, this would seem to be a problem with the java.sql.Timestamp
> implementation. However, when using a SimpleDataFormat to output the
> java.sql.Timestamp, the milliseconds are, in fact, present. (There's
> only a precision of three available as compared to Oracle's nine, but
> that's an implementation issue.)
>
> These two facts lead me to believe that either Oracle's JDBC drivers
> do not handle the java.sql.Timestamp correctly, or the Oracle instance
> isn't handling it properly. I'm apt to think that this is an issue with
> the JDBC drivers.
>
> At any rate, even if you do use the oracle.sql.TIMESTAMP to store the
> timestamp in Oracle, Castor fetches it using the java.sql.Timestamp
> and the milliseconds are gone again. This then causes the
> ObjectModifiedException because Castor's dirty check algorithm sees this
> field as having been changed. This is why setting the dirty attribute
> to ignore solves the problem.
>
> Bruce
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
