Flush, Set Autosave, Set("Autosave")

No, this is not the command to let you do what you'd like with that last guy's code. FLUSH forces cached writes of data to the disk. SET AUTOSAVE permits you to determine how often the automated flush will occur. Both are less necessary than they were with earlier versions of the software and less reliable hardware of the past.

Usage

FLUSH

FLUSH empties all internal buffers of data (which have nothing to do with record or table buffering) to be written to disk. Buffers are automatically flushed when the table is closed or a record is unlocked.In rare cases, the loss of a computer or the network before all disk writes are completed can result in the loss of data within a record, or even the corruption of a table header, leading to the dreaded "Not a table" error message. Visual FoxPro and its immediate predecessors seem to be better at this than the bad old days of dBASE III and FoxBase, but we're not sure how much of this is due to improvements in the product and how much is due to more reliable hardware and much more common UPSes. Also, new logic was added into the process of opening a file in VFP, so that if it detects the header is "one off" from the actual record count, it just increments the header count, invisibly and silently, and continues the file-open process. In addition, because releasing record and file locks automatically flushes the data (although not the file headers), the increased popularity of rapid lock-update-unlock techniques has probably also contributed to the overall reliability of our systems. Row- and table-buffering techniques that also commit data to disk as rapidly as possible alleviate most of the need for this command.However, in Doug's experience, buffering seems to update the data records, but not always the table and memo headers. Even an explicit FLUSH may not be the solution—he reports that FLUSH updates the table and memo file headers but not the CDX header. Closing a file, issuing an explicit FLUSH, or waiting for the timeout for automatic flushing (we think that that is five minutes, set internally and inaccessible to us) may still not be sufficient for the most paranoid. Realistically, the command is a FoxPro solution for something that is not a FoxPro problem—the problem is the environment in which you are asking FoxPro to perform. If your network suffers frequent crashes, fix it. Until you can, consider FLUSHes as a Band-Aid to lower the frequency of, but not necessarily eliminate, file corruption. If the crashing can't be stopped, consider a more robust data storage technique like client-server instead of the direct writing to ISAM files of the FoxPro DBF model.Forcing a FLUSH defeats the automated caching of Visual FoxPro and leads to degraded performance. Because writes are performed automatically upon the release of locks, the only situations in which FLUSH is likely to save more data is where tables are being bulk-updated in an exclusive or file-locked situation.Bottom line: If you're losing a lot of data, you can use FLUSH to improve the situation a little. But improving the online reliability of your system will be a far better long-term investment. We don't use this command much at all.

Usage

SET AUTOSAVE ON | OFF
cOnOrOff = SET( "AUTOSAVE" )

This is a second opportunity for you to force disk writes more often. Setting AUTOSAVE ON forces updates to be written when exiting READs or when control returns to the Command Window. While it is not documented as doing so, we suspect that setting AUTOSAVE ON also flushes buffers as each form is closed, since it is scoped to the data session. If you need to do a lot of updating to your system interactively or from the Command Window and have problems with the system staying up long enough for your changes to be written to disk, SET AUTOSAVE ON. The tradeoff might be slightly slower performance. As we mentioned above, in most cases it is much better to make the system more reliable than to drag down performance with commands such as these.