>>This is not a question, it's just in regard to VFP quality...
>>I support high-volume VFP system (1.5 GB, 4 million records in the biggest table) which includes (besides many other functionalities) 'report generator' module to print multiple (5-10K) reports usually as part of nightly batch. These reports essentially data (3-5 pages each) retrieved from multiple high-volume tables using SQL-Select sophisticated chain. The module generates reports into files and then another module moves these files into different printers based on file name and file windows timestamp (to provide right printing sequence).
>>Recently, the module was moved to high-power server (256M RAM) and testing it I saw that sometimes VFP works too fast, i.e. stamps consecutive report files with the same time (the same second) that can mislead printing module. So, I had to 'slow down' the system adding WAIT WINDOW "" timeout 1.0 on start of report routine ::)
>
>It is just awful the things we have to put up with. ;-)
>
>Also... the time function can be made to used 1/100's of a second. Definition below for time() from the VFP help:
>
>***
>Returns the current system time in 24-hour, eight-character string (hh:mm:ss) format.
>
>Syntax
>
>TIME([nExpression])
>
>Arguments
>
>nExpression
>
>The time returned includes hundredths of a second if nExpression is included. The numeric expression nExpression can be any value. However, the actual maximum resolution is about 1/18 second. Use SECONDS( ) for greater resolution.
>
>Return Types
>
>Character
>***
>
>It looks like you might be able to get away without having to slow down your code. Oh.. you can also use the SECONDS() command to get down to milliseconds.
>
>Let me know if this helped.

Evan, it wasn't a question, but thank you anyway. The problem is not with TIME() or SECONDS(). Printing module returns file timestamp using ADIR() and here it looks like limited to whole seconds.