Colin,

I feel that Jim B is right too.
But I really don't know how an average person, or especially a newbie to VFP, would have an iota of a chance to recognize such "misplacements"!

The idea of 'testing for one's self' really doesn't cut it with me anymore, given the complexity of all of the interrelationships both within VFP and also outside of it.

This "problem" seems to be yet another instance of sloppiness in the VFP documentation. This, and lots like it, has persisted through multiple versions of the documentation.
The VFP team may well have felt that they were improving the chances of attracting new developers to VFP when they delivered the classes and 'framework' with VFP6, but, frankly, I find their deployment, as documented in both the VFP 6 documentation and other literature (articles in mags) to be very light and highly confusing!

So now I see: unclear and erroneous documentation (of somewhat long standing for VFP in general), light documentation throughout, including new features, and sloppiness throughout. I would submit that this is hardly an environment to enable new people to learn the language.

Cheers,

Jim N

>Hi Jim,
>
>I think Jim B has hit the nail on the head with his explanation. I have to agree with you on your one point that, in this case, the documentation was as clear as mud (or the DVP during rushhour :-) .....for everyone else this is a Toronto commuter joke.
>
>Cheers
>
>>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().