Crap, now I seem to be having the issue with the jtds driver also.
Maybe I just get lucky sometimes and the dates just work. Most of the
time the time is off by a fraction of a second:
These two times should match....
01/28/09 03:29:16 PM INFO
com.nielsen.ondp.test.persistence.dao.gui.AssociateTest setLastLogin -
Today time: 1233174556616
01/28/09 03:29:16 PM INFO
com.nielsen.ondp.test.persistence.dao.gui.AssociateTest setLastLogin -
associate lastlogin time: 1233174556617
Here's some relevant info:
The test case:
Date today = new Date();
log.info("Today time: "+ today.getTime() );
associateDAO.setLastLogin(TestConstants.ASSOCIATE_ID_RICK);
Associate associate =
associateDAO.findByAssociateID(TestConstants.ASSOCIATE_ID_RICK);
log.info("associate lastlogin time: "+
associate.getLastLoginDateTime().getTime() );
assert associate.getLastLoginDateTime().compareTo(today) == 0;
<update id="setLastLogin" parameterClass="java.util.HashMap">
update NPPAssociate set lastLoginDateTime = #lastLoginDateTime:DATETIME#
where associateID = #associateID#
</update>
in the result map:
<result column="lastLoginDateTime" property="lastLoginDateTime"
jdbcType="DATETIME" />
Associate object has java.util.Date lastLoginDateTime
I've tried TIMESTAMP in place of DATETIME, didn't seem to make a difference
On Wed, Jan 28, 2009 at 3:08 PM, Rick <[email protected]> wrote:
> Maybe I'm setting things up wrong, but when I try to insert or update
> using java.util.Date the very last digit on the long of this datetime
> (date.getTime()) will be 1 fraction of second greater after either
> it's entered into the db or on the way out (I haven't investigated if
> it's on the way or n as the problem, but will shortly.)
>
> column is DATETIME, but regardless of driver my JDBC type I have to
> set to TIMESTAMP (although I tried DATETIME also)
>
> If I switch to the jtds sourceforge jar this issue seems to go away.
> Any ideas what I'm doing wrong so that I can get this to work
> correctly using jconnect?
>
>
> --
> Rick
>
--
Rick
