Sorry for the delay, but my phone line was stuck for a day.

>I ran into some very strange problems with a piece of code that performed heavy table accesses, and the only solution was to insert a brief delay between commands. The particular section of code produced combinations of three different fields in a table ("DestTable"), and each of the fields had an external reference table listing all possible values. The combinations I wanted to produce were those that were present in the "keytable" master reference table and where the individual fields were in the reference tables. So...
>SELECT DestTable
>SET RELATION TO trade INTO temptrad, postcode INTO temppost, product INTO tempprod
>*** Delay needed here ***
>APPEND FROM keytable FOR NOT EOF( "temptrad" ) AND NOT EOF( "temppost" ) AND NOT EOF( "tempprod" )

Setting a relation is one way to do it; I was using it without relation, like this:
APPEND FROM keytable FOR seek(trade, "temptrad" ) AND seek(postcode, "temppost" ) AND seek(product, "tempprod" )
This may give you some speed, because it does both things: the relation moves you to the right record in the lookup tables, and then you check EOF() to see if it succeeded. Seek() does both.


>3. The REPORT FORM "FOR/WHILE" clauses
>
>I can't get either of these clauses to work properly with the PREVIEW clause. What I'm trying to do is to only print a selection of records from a table, but the PREVIEW clause is giving me endless problems. The preview itself appears correct on the screen, but when the toolbar print button is clicked, all records are then printed -- not just the one(s) shown on the preview. The only solution I've found is to use a filter before the REPORT FORM statement: this restriction works with both the screen preview and the final printed report. But what's stopping the FOR/WHILE clauses from working?

I've generally decided to run all the reports off a prepared cursor, and not use the For/while clauses, mostly for preview problems.

>5. Corruption of source and destination files with COPY FILE
>
>This is a real serious problem. One of the functions of the application I'm developing copies a large number of files from a previous version (which runs under FoxPro 2.6) for conversion. I store the various filenames and directories (source and destination) in a table, and simply SCAN/ENDSCAN through this, using the COPY FILE command. However, almost every time, VFP later halts when using one of the copied files with a "not a table" error. The frightening thing is that as well as the copies of the files giving this error, the original files being copied can also fail in the same way. They're fine before the COPY FILE is performed, but afterwards they too can be corrupted. The workaround was to create a batch table using DOS COPY commands, and then to RUN the batch file, but I'd still like to know if anyone else has found file corruption with the VFP COPY FILE command.

This has not been documented, and I'm still not sure if I'm right, but it seems that, despite VFP's having a single-threaded model, its file functions (like COPY FILE) create independent threads, so a delay or check on accessibility on both original and copy may be needed if you have to use the copy right after it's created. If I'm right, the copying is not finished yet at the moment VFP moves to executing the next command.