...but you could *probably* do it with a hack.<BR><BR>Recall that both Access and VBS use a DOUBLE to store a date/time. Where the integer part of the number is the number of days since 30 Dec 1899 and the fractional part is the fraction of 24 hours.<BR><BR>SO...<BR><BR>SQL = "INSERT INTO table ( dateTimeField ) " _<BR> " VALUES( CDATE(" & CDBL(timeToMilliseconds) & ") )"<BR><BR>Now my question: How did you get the time in milliseconds, to begin with? Into VBScript, that is?<BR><BR>Completely untested. A wild-*** idea off the top of my head.<BR><BR>
...that maybe there's no reason to store the field as Date/Time. After all, how will you extract it and then display it with the milliseconds??? Maybe you should simply store it as a DOUBLE field??? And do all the manipulation to display milliseconds *outside* of Access???<BR><BR>
CDATE apparently rounds the DBL value you give it to the nearest second.<BR><BR>I think you are stuck storing it as a double.<BR><BR>Or, if you are getting the time from JS, just store the number of milliseconds as a long integer???<BR><BR>
...is that it *DOES* work in VBScript.<BR><BR>Demo:<BR><BR><%<BR>milliseco nd = (1/(60*60*24*1000))<BR>tick = Now()<BR><BR>dbltick = CDbl(tick)<BR>dbltock = dbltick + 20 * millisecond<BR><BR>Response.Write "Double diff: " & dbltock-dbltick & "<P>"<BR><BR>tock = CDate(dbltock)<BR><BR>Response.Write "ticktock diff: " & ( CDbl(tock) - CDbl(tick) )<BR>%><BR><BR>Both the response.write's give same answer.<BR><BR>But doing the equivalent in Access gives a zero for either answer, assuming that in the middle of the process you stuff the value into a datetime field using CDATE. Ugh.<BR><BR>
I was most concerned about date oriented math in SQL queries for external reporting tools. Milliseconds was a "nice to have" and the client has agreed to just deal with dates down to the second.<BR><BR>Thanks everyone.