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.

Yep.

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.

It's not complicated at all... BO.Load(PK) then BO.Save()


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

Why is it safer? Is there a problem with the automatic locking?

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.



It's optimistic. For this application, the whoever saves last wins approach is not a problem.

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.

I don't want to bind to the data because that puts data access in the UI. How do you do N-tier with table buffering?

Thanks,

Michelle