>Gar,
>
>>The grandchild query went something like this.
>>
>>Select * from grandchild where childkey in (select childkey from child where parentkey=parent.parentkey)
>>
>>A greatgreatgrandchild query would have been something like:
>>
>>select * from greatgrandchile where grandchildkey in (select grandchildkey from grandchild where childkey in (select childkey from child where parentkey=parent.parentkey).
>>
>
>I would have to agree that this is quite possibly the best n-level solution I've seen, if you ignore (!) VFP's limits on nesting and also ignore possible performance penalties.
>
>Usually, when I run across something like this -- an unsolvable general case -- I try to engineer around it. Especially since only a few people responded, I have to believe most people don't run into it, again suggesting they are engineering around it, most likely without a second thought.
>
>However, I have not been able to see my way around the example that caused me to examine this in the first place. Example: Business Rules state that a sales order cannot be saved without line items. In order to accept the save-parent-first philosophy, this rule has to go. Ho hum, probably not the end of the world...

Nope -- it can be done with just the modest denormalization of propagating the parent key down the entire child, grandchild etc hiearchy. You keep your business rules, do it your way and still save the whole thing at once . Basically, you lie to the screen and tell it that everything is a child of the parent -- even though at the database level you have a parent-child-grandchild great grandchild relation set up. (As previously mentioned in this thread you use filters so that user sees only the propery records grandchildren, many time great grandchildren or whatever at once.)