>>>>>AutoInc clashes with Table buffering applied on parent table. One may rethink interface to avoid these cases.
>>>>
>>>>The only other way (besides the kludge approach I already thought off) I see is to not allow to enter children unless we saved the parent.
>>>
>>>I think you exaggerate. Frankly, I never get in this situation (generally speaking I don't use Tableupdate, except special cases), but why do you need to have table buffering on parent? You could have row buffering and go by each record, saving parent record, getting Id, and then saving child records.
>>
>>I always give a choice to revert all the changes made and I always use table buffering.
>
>This can be done without table buffering :). This whole thing (buffering) appeared as a way to simplify code many years ago. At that time people knew how to do it without buffering, many people who started it after may believe that it just not possible.
>Btw, if you mean reverting on Save point, then it's done by Transaction, not by buffering.

I do not see a need for a transaction in a case of a single table updating. If we update multiple tables, then we do need to use transactions.

I took a closer look into the simple framework I adapted here and it looks like it was designed only to handle single table updates in row-buffered mode. I'm working on some changes to that as we speak.