>I don't bother with buffering because, by the time I'm attempting to make any changes to the table, the user has already commited to saving them. The record is only locked for the GATHER from my BO.

You can copy to variables, array elements, or properties, and do the editing there. I assume that is more or less what you do with your business object.

Buffering takes away some of this complication, meaning that you can edit the field "directly" - or so it seems in code. Actually, VFP works on the buffered version.

> But since VFP will lock it for me when I do the gather, I'm wondering if the RLOCK actually serves any purpose?

I think rlock() isn't required if you use buffering. Without buffering, locking with rlock() would be safer.

If you decide to take care of the buffering yourself (with your BO), another consideration is, do you want to emulate optimistic, or pessimistic buffering?

To emulate pessimistic buffering, you must rlock() as soon as, or before, the user starts editing.

To emulate optimistic buffering, you would only rlock() briefly when saving data - but then, you will also have to check whether another user made changes (it might be dangerous to overwrite these). This will require working with three versions of the record: 1) The one the user is currently editing, 2) The original version, when the user started editing, 3) The current value, which you have to read from disk again.

In this case, it seems simpler to me to just use optimistic buffering (mode 3 or 5), and check whether TableUpdate() is sucessful or not. That means, delegating lots of work to VFP instead of having to do it yourself.