>>>>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..)

As far as I can determine, VFP has a maximum resolution of one-half a second for datetime values. SQL Server, OTOH, has a resolution of 2 milliseconds.