Colin,

That was easier than I thought it would be. Here is an excerpt from VFP 5.a Help on TableUpdate (right at the end of it):

------- start of excerpt-----
Remarks

TABLEUPDATE( ) returns true (.T.) if changes to all records are committed; otherwise, TABLEUPDATE( ) returns false (.F.). If you specify 0 or 1 for nRow, the record pointer remains on the record where changes could not be committed and can issue AERROR( ) to determine why the changes could not be commited.

TABLEUPDATE( ) cannot commit changes made to a table or cursor that does not have row or table buffering enabled. If you issue TABLEUPDATE( ) and row or table buffering is not enabled, Visual FoxPro generates an error message. However, TABLEUPDATE( ) can still commit changes to a table or cursor that has validation rules. Use CURSORSETPROP( ) to enable or disable row and table buffering.

Changes are committed to the table or cursor open in the currently selected work area if TABLEUPDATE( ) is issued without the optional cTableAlias or nWorkArea arguments.
-------------------- end of excerpt -------------------

The third statement of the second paragraph is what I remembered.
As I read it, the "however" applied to the assertion in the prior statement, namely that " TableUpdate() ***cannot*** commit changes to a table or cursor that does ***not*** have row or table buffering enabled. ".

I inferred (and still do) from the third statement that TableUpdate() will commit changes EVEN IF THERE IS NO BUFFERING IN EFFECT if the table or cursor (to which i also equate, possibly erroneously?, a VIEW) that has **validation rules**.

Now I cannot say exactly what rules are being referenced here. Perhaps someone else can answer this.

I *don't think this means anything *implicit* (but here, again, I could be wrong) but rather assume that, since this is written under TableUpdate, then it implies a TableUpdate command is issued.

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

Hope this helps,

Jim N


>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().