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


Never prints anything besides "000" for me.

FOR x=1 TO 10
  INKEY(0.001)
  ?ttocEXT(DATETIME())
ENDFOR