>Why? Do you want to say that you add records to unbuffered child table before tableupdating parent one? If you don't then you just firslty tableupdate() parent record and then tableupdate() child view/cursor.

Yes, you're right. But that breaks up the processing. You have to TableUpdate the parent, then Replace the foreign key in the child, then TableUpdate the child.

The way my framework works, you add both the child and the parent record, default the fields that can't be defaulted automatically (including replacing the parent foreign key in the child record), allow edits, then do the TableUpdates.

I guess this approach isn't better than another, though. It does seem to me that it makes the child record logically consistent at an earlier stage, but that's not necessarily better.