Posted by vikram.mankar on 01/30/07 15:18

I should have known that! Darn...

Thanks.

On Jan 18, 3:58 pm, Roy Harvey <roy_har...@snet.net> wrote:
> This is a documented behavior of the datetime datatype. As the Books
> On Line says: "Values are rounded to increments of .000, .003, or .007
> seconds". It applies to all versions, and I would not expect it to
> ever change.
>
> If you must keep it to the exactmillisecondthen you can not use
> datetime.
>
> You could split the information into two columns, say one part for the
> date (could use smalldatetime) and the other for milliseconds since
> midnight. Or, since smalldatetime is to the minute the second column
> would just have seconds and milliseconds. There are countless
> variations possible, none will make processing simple.
>
> Roy Harvey
> Beacon Falls, CT
>
> On 18 Jan 2007 11:15:14 -0800, vikram.man...@gmail.com wrote:
>
>
>
> >I'm running into a constant issue ofSQLServermodifying the
> >millisecondpart of a timestamp insert from another application. The
> >application inserts timestamp which includes amillisecondportion as a
> >string (varchar). But when anSQLServermoves this data to another
> >table (for reporting), the string is inserted in a datetime field, the
> >millisecondfield invariably changes by 1-2 milliseconds for every
> >single data point inserted. Given the time critical nature of this data
> >(to amillisecond), its almost impossible to avoid this other than to
> >leave the data as string type. But this drives the analytical reporting
> >folks wild as report queries based on time criteria are getting messed
> >up. Any ideas how to forceSQLServernot to mess around with the
> >millisecondvalue? Does this problem exist withSQLServer2005 as well?- Hide quoted text -- Show quoted text -

[Back to original message]