Here's a simplified example I ran up for somebody, a while back, for what you're talking about. It starts with a Customer Table, which would be one step up in the hierarchy, above your PO Table, which you may or may not need, where customers can place multiple orders, and each order can have multiple items:
CustomerTable
CustomerID 'Primary Key
CustomerFirstName
CustomerLastName
CustomerHomePhone
Customer CellPhone
CustomerStreetAddress
CustomerCity
CustomerPostalCode
...and so forth
OrdersTable
OrdersID 'Primary Key
CustomerID 'Foreign Key
OrderDate
MethodOfPayment
...and so forth
OrderItemsTable
OrderItemsID 'Primary Key
OrdersID 'Foreign Key
ItemName
ItemQuantity
ItemCostPerUnit
...and so forth
Notice that the Tables 'cascade'
- The Primary Key of the first Table becomes the Foreign Key of the second Table
- The Primary Key of the second Table then becomes the Foreign Key of the third Table
To display all of these in one Form and to be able to enter New Records or Edit Existing Records in all of these Tables:
- The Main Form would be based on the CustomerTable
- The first Subform would be based on the OrdersTable and linked to the Main Form by the CustomerID
- The second Subform would be based on the OrderItemsTable and linked to the first Subform by the OrdersID
Even if you don't need the Customers Table, this should point the way for you.
Linq ;0)>
The problem with making anything foolproof...is that fools are so darn ingenious!
All posts/responses based on Access 2003/2007