Information générale
Catégorie:
Codage, syntaxe et commandes
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().
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement