In my cases we use tablebuffering also - things that today would be put in a document NoSQL database by others are written of to more than a handful of mostly normalized tables. vfp TableUpdate triggering the CA did not feel right, so our CAs have a method .DoTableupdate, which calls Tableupdate on the cursor the CA is responsible for. Biz objects responsible for validating each edited record and also for spelling out the wehre clauses used in the CA for collection/many-record types of use cases. We often have the need to keep m:n in edited/unsaved state till everything is ok, and keeping those in a cursor (sometimes shown in a grid) is often easier than having a collection biz object - getting min(PossibleDriver.Age) via SQL is also more natural for dinosaurs like me for "document validation".

>Suppose that makes sense - if you're using TableBuffering which i also always found to be fairly redundant if you have an adequate business layer. All the buffering I tend to do is done is not done on data records but on objects that are only written into the database when they are final - no need to buffer. I've always thought of this as an odd model that makes sense only if you work on data directly which IMHO is a bad design choice in the first place.
>