ROFL ... Yeah, looks like I'm gonna be forced into a bad database design. I wonder which of Boyce and or Codd's normalization rules is being violated ... hey... wait a sec ... maybe none.

>Well I never!! < storms off >
>
>< comes back later >
>
>Just kidding!
>
>Actually we did this for a POS system. We had a model like parent/child/grandchild/great-grandchild/great-great-grandchild. To avoid the requerying, tableupdate/tablerevert issues we duplicated foreign keys within the each succssive table down the line. At any point in the chain we could find all descendant records using one requery per view. Then by applying the appropriate filter on the child views, we displayed the appropriate data. When a save was done, it commited all changes everywhere.
>
>Otherwise, you are forced into a problem of saving data temporarily from edits in the grandchild view if the user moves the pointer in the child view and then restoring those edits if they move back. Basically, you have to create something like a transaction table and then read from it for display purposes. You would also have to read from it on parent Save and write all changes back to the appropriate views so they would be updated as well.