Don't forget that with optimistic buffering, VFP will lock the records only when commiting the modifications to the table. AFAIK, there is no significant performance penality using table buffering, but there is more chance of conflict. In case of conflict, you can use GetFldState() to determine which records are causing the conflict and do some action based on that information.

Keep in mind that, IMHO, table buffering is safer than record buffering and is a must if you want to use transactions.

---

>Thanks for the information. I was under the impression that buffering = 5 meant that you would tie up the whole table while you were saving an edited record. I was thinking that would be bad when using a huge DB where you might have multiple users editing records at the same time, although not necessarily the exact same record at the exact same time. I am quite certain the people I am working for will not let me even think of using buffering = 5. They don't like me using any buffering, but I am anyway. They are really afraid of buffering and its record/table locking and update conflict issues in a multi-user environment. I will also keep reading and see if I can make sense of all this buffering stuff. And I will rethink and consider your buffering = 5 suggestion. Thanks again.