I shouldn't have included the superentity, all it does is confuse the issue. There is always a superentity in an application. Sometimes it's not part of the data model. For example, when you write a car parts application for a repair shop, the repair shop may be the superentity but not necessarily have repair shop specific tables in the app. So the role of the superentity can sometimes be loosely linked.

As to the edit paradigm.....doing drill-downs so that you are only editing from the parent-child standpoint (the parent begin relative) works, but I find *it* can be cumbersome. Look at the Office paradigm: If you edit an Excel worksheet and add macros, graphs, and new worksheets to the workbook and then exit without saving changes, all changes are gone.


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