Colin,

Sorry to be replying here, but there was no options selectable at the bottom of the actual message (regarding your findings on "VALIDATION"). . .

As I said earlier " As I've often said, VFP documentation is very difficult to discern, even at the best of times. ".

My guess would be that the TableUpdate() writeup is correct and that the pertinent condition as documented there has been omitted in the VALIDATION statements. After all, it would be totally in left field to make such an assertion in TableUpdate if there actually is no basis for it.

But I don't know, that's for sure.

good luck,

Jim N


>OK, thanks Jim. I'll try and do a little digging as well.
>
>>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().