>Erik,
>
>Thanks for the input. I like your second method. The problem I have is that the Order Header table has 82 fields (most of which are Logical). A grid would probably be to cumbersome for data entry. A multi-page form would probably work best for the Order Header table with a grid for the order line-item table.

I almost never handle data entry in a grid, unless a client insists. I use grids for picklists and quick reference. Toe edit, highlight a row and click to open up an edit form, or doubleclick a record to do the same.


>I guess what I'm still not sure about is coordinating the new/save/revert logic for all three entities. Based on the above information, would you still go with your "preferred method" and how (conceptually) would coordinate the new/save/revert logic amongst the three entities?

Each entity gets its own add/edit screen with a save and a cancel button. The screens previously described are mainly record picking screens. When an order entry is highlighted, and the user clicks the add sub-order button, a sub-order is added for that order, and the same thing with sub-orders and line items. Also, when an order is deleted, the delete cascades down to the sub-orders and line-items.

I hope I am not just confusing you further. HTH