>>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 ::)
>
>Why don't you create a table that lists reports to be printed. It could have a structure like this: ReportFile, Sequence, Printer, Processed. With this structure your print dispatching module could read this table for the printjob with the lowest Sequence and !Processed, print the ReportFile to Printer, and set Processed to .t. when done. This would eliminate the wait and should be faster than an adir(). You could also reset processed to .f. if a particular report needs to be reprinted because of a printer problem.
>
>I realize you are comfortable with the current performance, but your workload may increase in the future.

Thank you for your suggestion. However, I am pretty comfortable with current speed as you see from the posting. Also, workload is so high that I don't believe that it will be increased. Currently, it works without any additional tables, and this is fine. Actually, there are few (not one) printing modules which dispatch report files in different geographic locations (it works on WAN).