Yeah, the collating sequence was set to Machine. Garrett made a reply somewhere in this thread about floating point math, so there must be some going on behind the scenes -- assuming that we can trust him :)

>>There were a few apparent duplicates in the table. When I tried to add the primary key index, it gave me one error message (I assume that as soon as it finds one violation, it just terminates the whole thing). However, in "manually" comparing all of the datetimes (using an equality test with either SQL or a loop), there are no duplicate datetimes (just the ones that look like duplicates). Clear as mud, isn't it :)
>
>Are you sure the collating sequence on that tag is Machine? Other collating sequences, when used on stuff other than strings, may yield gray hair, higher blood pressure and neurological disorders.
>
>Internally, the datetime is two integers - one for the Julian day number, and the other for the number of milliseconds. There should be no rounding issues here; if you add 1, it should add a thousand milliseconds to the right portion of it, period. I would really be surprised if adding 1 to a datetime ever managed to produce a duplicate.
>
>However, if you use a General or any other collating sequence, the key value is interpreted as a string, and then converted into a two-byte equivalents of the characters it represents. These collating sequences are also case blind, which means that two values differing by 32 on any of the bytes in the 65 to 90 range may yield the same final key value, thus giving you duplicates.