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

IMO a parent table has a chance to become a child-and-parent table in multiple relation scenarios - customer enhancement wishes...
If all are table buffered right from start, less changes later

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

OTOH would coding against established FWK idea, implementation and existing code base fall into a border area for "specific problem" ;-)

My technical reasons for preferring table buffering are:
a) less danger from (mostly vfp specific) automatic record pointer moves - even if those are actively avoided.
b) conceptually I try to see ANY client (must not be vfp coded!) always as "offline-first", even in LAN setups - from client side caching to checking connection+error handling if save not possible. For me that mandates "Save" as a first order action.

Personal preference of SW able to try different scenarios in a "light" way does colour my opinion, but b) is a part of that as well ;-)