Still, I'm not sure I see the problem. Let's say there are three grids, one with customers, one with invoice header records, one with invoice line items. The user navigates to a customer record. This forces a requery of the cursor/view used by the grid with the invoice header records and it then displays all the invoices for the current customer. It also forces a requery of the cursor/view used by the grid that displays the line items and it displays the line items for the first invoice in the invoice header grid. Then the user drops down to the second grid and moves through the invoices. Moving through these rows causes the cursor/view used by the line items grid to requery and all the line items of the current invoice are displayed. Before a requery the user is asked to save changes if there are any.

But if you structure the SQL statements properly, you can get a cursor with the invoice for the current customer and all the line items for the current customer and make those updateable and not have to save until the very end, which would save changes to all records at once regardless of the invoice that was changed. Seems like you can do it either way. Save on each invoice that is changed or save all at once no matter how many invoices were changed for that customer. And this would be without putting the customer FK in every table. You'd use filters in this scenario, but they wouldn't be needed in the first one.


>I'm glad you asked! You'd have to force the user to save all changes, before you could requery either the child or grandchild cursors.
>
>With the FKs available throughout the hierarchy - you gain the ability to SET FILTER or SET KEY on the children/grand children as the user navigates without saving anything.
>
>Admittedly this isn't the best example, because you'd seldom add a customer record and then add invoices and line items per invoice without saving, but with this approach you could do it!