>Hello all,
>
>I have an Order Entry/Production Scheduling project underway for a textile manufacture client. Each order placed consists of multiple custom products designed to the order placing customer's specs. My client requires for each order placed, multiple sub-orders can be attached and in turn an order-line-item will attach to the sub-order. That is to say that each Master Order may have several Sub-Orders. In addition, each sub-order could have a different ship-to.
>
>My table design consists of an Order Master table, Order Header table (Order Specs) and an Order-Line-Item table (quantity and unit price). There are also various look-up tables for employees, shippers, terms, etc.
>
>My question is conceptually, how should I integrate the "master order table" parent to the "order header" & "order line-items" children within a Form? My concern is "triggering" new orders and "looking-up" old orders.
>
>TIA
>
>Don Burton

It really depends on how 'at-your-fingers' you need all of this information to be. What it sounds like to me is a one-to-many-to-many situation. I have dealt with these before in a couple of different ways. The first is a form with based on parameterized views with 3 grids, the top bring the grandparent, the middle the child, and the bottom the grandchild. The afterrowcol change event of the top grid triggers a requerying of the middle, which triggers a requerying of the bottom. There is a good amount of code involved in poutting together a form like this, but it is completely do-able. The second (and my preferrable) method is to break the form up into two or three one to many forms. That is, have your main form consist of a grid from which to choose orders. Double-clicking on a row brings up a form that shows all suborders for that order and double clicking a row on the suborder form brings up a line item form.

You can also compromise between these two methods and combine the strategies: Clicking on an order brings up a one-to-many form showing sub-orders and line-items.

I think the separate forms method is the way to go, because it separates save/revert logic for each table into their own form, and stick with a one form/one entity scheme.

If any of these suggestions sound good, but you're not sure how to get started, let me know and I'll expand a little.