Hi Tony, Have you already done the fix? Is it simply a matter of creating a new java.sql. Timestamp (with the correct values stored in it) and returning it instead of the java.sql.Date? I have a patch for village to take care of the Oracle-BLOB problem and you have one for Oracle-Timestamp. I would like to combine both and have one single patch. Do you mind sending me the source or diff?
-Sarav Quoting "Foster, Tony" <[EMAIL PROTECTED]>: > This is a problem with the Oracle JDBC driver. In their wisdom, Oracle > decided that the 9i driver would interpret their database DATE type as > java.sql.Date, and thus truncate the time-to-the-second portion that it > stores. This, despite the 8i driver treating it as java.sql.Timestamp. > > What you need to do is patch the Village software to override this bizarre > not-a-bug-according-to-Oracle behaviour. I will send the jar to you > directly. > > Regards > > TT. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of [EMAIL PROTECTED] > Sent: 15 June 2004 2:46 pm > To: [EMAIL PROTECTED] > Subject: DATE and TIMESTAMP in Oracle with Torque 3.1 > > > > > I am using Torque 3.1 with an Oracle DB. I am trying to create tables that > have date/time fields. I find that it makes absolutely no difference whether > in the xml I declare the columns as DATE or TIMESTAMP; the DDL and code > generated are exactly the same. The effect of this is that the time > component of the timesamp is removed before the data is written to the DB. > For both DATE and TIMESTAMP fields the generated columns have SQL type DATE > and java type java.util.Date. > > There is a secondary problem. When I retrieve a row from the DB the > constructed date object is of type java.sql.Date instead of java.util.Date. > The causes an InstantiationException when the returned object is > subsequently passed to java.beans.XMLEncoder because the actual value does > not match the declared type. The documentation for java.sql.Date in fact > warns you that it should NOT be taken as a sub-type of java.util.Date. > > > So, it looks as if we need two fixes: > 1. To get full timestamps stored in the DB for Oracle (AFAIK the > implementation is correct for mySQL) 2. To ensure that the actual value of a > retrieved date or date/time matches its declared type. > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -------------------------------------------------------------------------------- > The information contained herein is confidential and is intended solely for > the > addressee. Access by any other party is unauthorised without the express > written permission of the sender. If you are not the intended recipient, > please > contact the sender either via the company switchboard on +44 (0)20 7623 8000, > or > via e-mail return. If you have received this e-mail in error or wish to read > our > e-mail disclaimer statement and monitoring policy, please refer to > http://www.drkw.com/disc/email/ or contact the sender. 3166 > -------------------------------------------------------------------------------- > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- There are 10 kinds of people in the world, those who know binary and those who don't. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
