I've been using Visual FoxPro v5.0a under Windows 95 for the last eight months, and at regular intervals I've come across some serious problems. Each time I've been able to find a workaround, but if anyone can tell me what's going on, I'd be very grateful. I apologise if this message is longer than the accepted norm, but I'm desperate to solve some of these problems.


1. A pause is sometimes needed between VFP commands

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" )
This code was being called from two different places, and the problem was that it produced different numbers of keys. I used LIST STATUS to check that all VFP settings were identical: the only difference was the number of tables open and the work areas associated with each. But since I always use specific aliases for each table and never reference work areas directly, I couldn't see what the problem was (it was also intermittent -- sometimes it happened every time, other times it worked perfectly). Inserting a two second pause fixed the problem absolutely, producing the same number of keys each and every time no matter how the code was called, but I still feel uneasy about the approach. Has anyone else encountered a timing problem like this?


2. The REPORT FORM "ADDITIVE" clause ("... TO FILE ADDITIVE")

The clause is undocumented, but it works fine if it's used with the ASCII clause: the reports get properly concatenated to the output file. If I use it with graphical reports (i.e. without the ASCII clause), no error is produced, but the output file gets overwritten each time. I can work around this by directing the reports to individual files and using DOS to copy them together into a single file, but is there any way to get the ADDITIVE clause to do the job? And if the clause is handled by VFP, and it works, why isn't it documented?


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?


4. The REPORT FORM "PREVIEW" clause (again)

Yes, I'm having real fun with this PREVIEW clause. In addition to the problem above, the PREVIEW clause is giving me inconsistent behaviour even when the FOR/WHILE clauses aren't being used. Printing a report without a preview, and then printing from a preview, can give different results. The main case when this happens is when the table just has a single row. When I do a REPORT FORM without PREVIEW, it prints as expected: just a single row. But when I do a REPORT FORM with the PREVIEW clause, it appears correct on the screen, but when printed the row is copied so as to fill the entire page. The only complication is that the table isn't actually present in the report's data environment: I open it beforehand in code. Anyone have any suggestions for what's happening?


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.