Hi Todd.

>> I suppose the downside with table buffering, if I understand correctly, is that if the update bombs a batch of transactions could potentially be lost. Has this been a problem for you? <<

Not at all. Anything you can do with row buffering, you can do with table buffering. The advantage is that you, the developer, and not VFP determine when the update will take place < s >.

The TABLEUPDATE function takes some parameters. The first of these specified the range of record to update ( 0 = current row, 1 = all rows ). All you have to do is write some code that checks for changes and updates the current record when the user attempts to navigate to a new record.

The only time I TABLEUPDATE more than the current row is if I am allowing users to do data entry in a grid. And even then, I generally update when they move to a new row in the grid. Depends on what they are editing and why.

Marcia