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

It does have a resolution of milliseconds, only the conversion to/from characters has a resolution of a second.
You can view the 'complete' datetimevalue with the following function:

function ttocExt
* ttoc replacement to include milliseconds
LPARAMETERS ptDateTime
lnMilli=ROUND((ptDateTime-DATETIME(YEAR(ptDateTime),MONTH(ptDateTime),DAY(ptDateTime),hour(ptDateTime),MINUTE(ptDateTime),SEC(ptDateTime)))*1000,0)
IF lnMilli<0
ptDatetime = ptDatetime + 1
lnMilli=lnMilli+1000
ENDIF
RETURN TTOC(ptDateTime)+'.'+PADL(lnMilli,3,'0')

Hope this helps...