>Corporation (superentity, only one)
>Company (Parent)
>Division (Child)
>Product (Grandchild)

> snip

>(and, no, I don't take kindly to drill-down edit structures....you should edit everything about an entity with one edit session)

OK John, I know what your getting at but something in this example doesn't make sense (bear with me while I try to put my finger on it).

I agree with your preference to edit everything about a single entity in one edit session. But your example is using 4 entities in my opinion. When I've hit upon this type of situation in my experience, the requery song and dance never presented a problem. Let me try and relate this to your example...

When dealing with a superentity, like Corporation in your example, I've always had the user select that on the way in to any type of data viewing or data manipulation form/process. So from the start, I have my corporation parameter specified.

As far as editing, I can see the Company and Division relationship being edited in one form/one session since their domains are directly connected. But assuming Product(s) would be a 'many' side of a one-to-many relationship, I would make that a separate edit form/process... or at the least a separate pageframe. So since I would handle it that way, I guess the drill down type of requery necessity isn't as cumbersome.

Plus too in my experiences, when you have data relationships that extend beyond Parent-to-Child, you have a lot more room for the base functionality of the app to grow and extend of te life of the app. So by separating the edit processes to be more specific to the entity (and not specific to the entity and all it's relatives) I've found less need for ripping out and redoing work on subsequent release versions.