Ian,
I'll try and answer what I can.>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" )
After setting a relation you must move the record pointer to "set" the related pointers. Issuing a GOTO RECN() in the master work area will do this for you. >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?
>
An option is left undocumented if it hasn't been thoroughly tested or there are problems with its functionality. Using undocumented options is done at your own risk. These options may change or even disappear in future versions of the product.>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?
>
This is a known problem, the Print button does not reissue the FOR or WHILE clause ofr the report form, it does a simple report form without those clauses. The solution is to use a fitler of a query to manage the data before you call the report preview.>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?
>
This is again the same problem. If you remove the alias references from the fields in the report you will find that it is printing the entire table. This often occurs when the currently selected work area is NOT the one that the data is being printed from. The current work area controls the number of detail lines while the data is comming from another table where the trecord pointer is not moving. >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.
I have not seen this problem.
