>Here is something I posted on ProFox a while back. I believe it is related:
>
>This may be old news to some, but it was new to me so I am going to post it.
>I created a key on import of time slips into a VFP table. The purpose of
>the key is to make sure that no duplicate slips are imported. The slips
>have a "from" and a "to" that are DATETIME() types. I selected an arbitrary
>DATETIME() of June 7th, 2003 at 10:00. On import, my key is the number of
>seconds gained by "lnkey = mytable.from - ltbasedate".
>
>I put this into production and when importing, I noticed I got about 30%
>duplicates - consistently! After a lot of debugging, I noticed that
>mytable.from - ltbasedate consistently generated different results (off by
>10) when run in different programs. For example: The key was 10000 when
>the slip was imported and 9999 when I checked to see if the slip was already
>on file.
>
>The solution was: "lnkey = ROUND(mytable.from - ltbasedate, 0)".

Yes, that's the problem. One can never be sure whether two datetimes will ever be equal, because both may contain an unknown number of milliseconds off the visible value - and these milliseconds are 1) hidden, 2) represented as floats when you take a difference between two values. At least it would be much better if they would behave like currency with 3 decimals instead of four.

And then as VFP goes further down its road toward SQL Server compatibility... how about the fact that SQL Server stores and displays the milliseconds. Will we also be able to see them and use them in our datetime fields? Something like Set Milliseconds ON/OFF would help.