>>>I tested 3 and 5 and it seems to not make a difference. The other thought was whether it matters performance wise or not if it is 3 or 5 (does VFP somehow have to scan all rows for changes if it is a 5?).
>>
>>That depends on the 1st parameter in tableupdate() - check to see what your framework uses there. It may go one record at a time so it can check each record (postsave etc) or do them all at once and then get recno()s (of those causing an error) in an array (last parameter of tableupdate()) or it may not even care. Look under the hood.
>
>Disagree. Unless reasons are given for a specific problem, ***always*** use table buffering - if biz logic needs working via single record tableupdates, implement logic to fire for each record - do not let possible "vfp-automatic" record pointer move fire record saves

We do 3 for parent tables. In our case validation, logging and other processes is build into cursoradapter so it cannot save without validating the record. OTOH we try to do as much as we can to prevent accendental automatic movements of the record pointer because there are probems relating to that regardless whether you use 3 or 5.

There isn't a strong reason we do 3 other than the whole 15 year old framework has been build on it.