>>>Actually, VFP rounds values to the nearest second and doesn't save the original values.
>>
>>As a matter of fact: VFP DOES store the milliseconds in the DBF, it only displays the time rounded to seconds.
>>You can test this quite simply by storing a datetime, add .001 seconds (sometimes .002 is needed because of floatingpoint rounding) and store that again in another field.
>>Retrieve them, substract them and look at the dirfference.
>>
>>CREATE CURSOR temp (time1 T, time2 T)
>>INSERT INTO temp VALUES (DATETIME(),DATETIME()+0.002)
>>? trans(time2-time1,'9.99999')
>>? (time2-time1)*1000
>>
>>*strangely the transform() prints 0.0000, but when multiplied with 1000 is does display 2 (the amount added earlier)
>
>Jeroen,
>
>I'm sorry but I must disagree. My hypothsis was formed by a recent assignment.
>
>The assignment was to transfer data from Teradata (an RDBMS by NEC) and SQL Server 2000.
>
>The source table had a compound primary key based on an order number and a creation date and time (in Teradata's data typing it was a timestamp). I did the translation of the data types to SQL Server, using a datetime, rather than timestamp because each time a record would be inserted, it (SQL Server) would update the timestamp. This is something that would've made future retrievals impossible.
>
>Using SPT and VFP 8.0, I downloaded the data to my computer. When I tried to send the same data to SQL Server (having the same primary key constraints), I got 199 violations of the PK.
>
>So I tried using another tool. In this case when I tried to insert the records, I got zero violations of the constraint. In looking at these records in the Enterprise Manager, it turns out that there was, indeed, a difference of a tenth of a second or less.
>
>Keep in mind that exactly the same drivers were used, so that can't be the problem.
>
>If you or anyone else has an explanation, I'd be happy to hear it.

That is caused by the rounding that VFP does when converting a string to a timedate value and back.
You can calculate within the timedate with milliseconds, but when you convert it to a string (like with ttoc() ) it will round its value to whole seconds.
Updating a SQL-server with a timedate will cause it to convert the timedate to a character string, causing it to lose its millisecond resolution. (It might also already have lost its precision when it read in the timedate value..)