If you want to protect data during updates, use buffers. Visual FoxPro record and table buffering help you protect data update and data maintenance operations on single records and on multiple records of data in multiuser environments. Buffers can automatically test, lock, and release records or tables.
With buffering, you can easily detect and resolve conflicts in data update operations: the current record is copied to a memory or disk location managed by Visual FoxPro. Other users can then still access the original record simultaneously. When you move from the record or try to update the record programmatically, Visual FoxPro attempts to lock the record, verify that no other changes have been made by other users, and then write the changes. After you attempt to update data, you must also resolve conflicts that prevent the changes from being written to the original table.
Choosing a Buffering Method
Before you enable buffering, evaluate the data environment to choose the buffering method and locking options that best suit the editing needs of your application, the record and table types and sizes, how the information is used and updated, and other factors. Once you enable buffering, it remains in effect until you disable buffering or close the table.
Visual FoxPro has two types of buffering: record and table.
To access, modify, and write a single record at a time, choose record buffering.
Record buffering provides appropriate process validation with minimal impact on the data update operations of other users in a multiuser environment.
To buffer the updates to several records, choose table buffering.
Table buffering provides the most effective way to handle several records in one table or child records in a one-to-many relationship.
To provide maximum protection for existing data, use Visual FoxPro transactions.
You can use transactions alone, but you gain additional effectiveness by using transactions as wrappers for record or table buffering commands.
Choosing a Locking Mode
Visual FoxPro provides buffering in two locking modes: pessimistic and optimistic. These choices determine when one or more records are locked, and how and when they're released.
Pessimistic buffering prevents other users in a multiuser environment from accessing a particular record or table while you're making changes to it. A pessimistic lock provides the most secure environment for changing individual records but it can slow user operations. This buffering mode is most similar to the standard locking mechanism in previous versions of FoxPro, with the added benefit of built-in data buffering.
Optimistic buffering is an efficient way to update records because locks are only taken at the time the record is written, thus minimizing the time any single user monopolizes the system in a multiuser environment. When you use record or table buffering on views, Visual FoxPro imposes optimistic locking.
The value of the Buffering property, set with the CURSORSETPROP( ) function, determines the buffering and locking methods.
The following table summarizes valid values for the Buffering property.
|To enable||Use this value|
No buffering. The default value.
Pessimistic record locks which lock record now, update when pointer moves or upon TABLEUPDATE( ).
Optimistic record locks which wait until pointer moves, and then lock and update.
Pessimistic table locks which lock record now, update later upon TABLEUPDATE( ).
Optimistic table lock which wait until TABLEUPDATE( ), and then lock and update edited records.
The default value for Buffering is 1 for tables and 3 for views. If you use buffering to access remote data, the Buffering property is either 3, optimistic row buffering, or 5, optimistic table buffering. For more information on accessing data in remote tables, see How to: Query Multiple Tables and Views.
Set MULTILOCKS to ON for all buffering modes above 1.