Hi Jim,

Wow that was quick! :-)

I'm using VFP6 and the documentation for TABLEUPDATE() says the same thing. However, I also found the following in the documentation under Chapter 7: Working With Tables:

Enforcing Business Rules
You can enforce business rules for data entry by creating field-level and record-level rules, called **validation rules**, to control the data entered into database table fields and records.

validation
The process of checking whether entered data meets certain conditions or limitations. See also field-level rule, record-level rule.

field-level rule
A validation rule associated with a field that is activated when the field value is inserted or changed, and most often used to verify data entry and correctness. Field-level rules are activated before record-level rules and triggers, and work during **BUFFERED** updates. Contrast trigger.

record-level rule
A validation rule, bound to a record, that is activated when a record is inserted or changed, and most often used to verify data entry and correctness. Validation rules do not apply when records are deleted. Record-level rules are activated after field-level rules and before triggers, and work during **BUFFERED** updates. See also field-level rule. Contrast trigger.

To me the documentation is contradicting itself. What's your take on this?

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