Steve,
It's a good format. If I were doing it I'd make the grid on the first page show only the fields needed to define the child record - Maybe only a description field. And make the grid Read-Only so all editing MUST be done on the second page. A double click on any grid item should take you to the correct item on the second page.

The Next/Previous buttons can be handled in 2 ways. First (and simplest) is to have 2 sets of buttons, one on each page, each linked to the appropriate table.

The second method is to have a single set on the form, and check to see which page is active (pageframe.ActivePage property).

Same methods would work with your add/delete buttons.

You WILL need to have Next/Previous buttons for the child records on the second page so the user can make changes on several records without returning to the first page.

Also, PLEASE use parameterized views not a filter to define your child records. It's harder at the beginning, but MUCH simpler in the long run.

HTH
Barbara

>I'm attempting a 2 page, page frame layout.
>
>The first page holds fields of the 'one' table with a number of long fields that will the fill the top half of the page - the bottom half of the page is a grid with some fields from the 'many' table, most of the fields will need to be scrolled to be visible.
>
>The second page holds all of the 'many' table fields laid out for easier data entry; with a few fields from the 'one' table displayed at the top to help identify the 'one' record that we're adding 'many's to.
>
>Is this layout workable?
>
>I'm puzzling of how best to use controls so user can easily add/edit the 'one' fields or add/edit the 'many' fields. I'd expect the next/prev/top/bottom buttons to manage the 'one' table with the 'many' along for the ride. As I write this I'm wondering if a child form that takes the place of page two might work better.
>
>I'll have to manage key fields in the background.