>Hi Marcia,
>
>Thanks for the input. I'll keep this in mind on my next project. Correct me on this one, Table buffering with Pesimistic Locking Mech works with multi locks and single record situations so it'd be more flexible in the long run to stick with the Table as opposed to single or row locks and TableUpdate/TableRevert eliminate another scatter and multiple replace commands ?
>
>Checked the book after your first reply and thought you were going to take me to task over my latest misconception.
>
>Thanks,
>
>Don
Hi Don.

Multilocks must be set on before you use buffering of any kind. I personally think that you are better off with table buffering because with row buffering VFP will automatically do a TableUpdate() any time you move the record pointer. And, as I said earlier, there is the problem of data corruption in VFP 3.0 with row byffering. I also think that it would be better to use an optimistic buffering scheme. You don't want to lock all of your users out of a given table for any period of time, do you? What if someone is making updates to a table that is locked and goes to lunch before the table is unlocked? In addition, if you ever have to upsize, you will have to use optimistic buffering.

Marcia