Colin,

I'll try (hard, cuase it will be) to find the actual reference.

Then perhaps one of us here can clarify as needed.

I'll let you know of success of finding one way or the other.

Jim N

>Hi Jim,
>
>Interesting info. Just want to clarify to ensure I'm understanding this correctly. By VALIDATION rules do you mean triggers? When you say a commitment *can* occur do you mean an implicit TABLEUPDATE() like when the record pointer is moved during record buffering?
>
>>Hi Colin,
>>
>>Just a little point (but it serves to show how tricky VFP can get). . .
>>
>>somewhere I remember reading that there *is* an exception to the *need* for buffering when using TableUpdate() and I believe that it was related to the existence of VALIDATION rules for a (.DBC) table or view. In that case it said that committment *can* occur regardless of the buffering chosen.
>>
>>Cheers,
>>
>>Jim N
>>
>>
>>
>>SNIP
>>>>
>>>>You should make a choice: if you use RLOCK() then you don't need in buffering at all.
>>>
>>>I wouldn't say that Ed. You still need buffering to use TABLEUPDATE() and TABLEREVERT().