I can't seem to get off the starting line.   I want to have a LineItem db that is a subform of PurchaseOrder db form, and also a subform of SalesOrders db form.    I have been advised to use natural linking.  What I have done is this:

- created a LineItem db, a Purchase Order db, and a SalesOrder db.
- I added the LineItem db as a subform in the PurchaseOrder db.
.         the LineItem db then shows up under the PurchaseOrder db, and displays the 'LineItem!Form'. I
- I added the LineItem db as a subform in the Order db.
- The LineItem db shows up under the Orders.db on the menu tree, but no form.  So I added a layout form and called it  sLineItem.

         But when I saved it and reconciled the app, then the sLineItem form doesn't show up under the SalesOrder.db.   It shows up under the PurchaseOrder.db (under the LineItem form that is under the PurchaseOrder.db).
         And the LineItem.db under the SalesOrder.db on the menu tree still says I need to design a layout for it.

Please advise (I hope my description is clearer than my thinking!!)

Thanks, Bob!  I'll follow your advice.  I had a thought - what if I build an Inventory database that will serve two purposes - 1) the POLines sub db can update (via on-exit programming) the just-placed-PO-current ItemCost into the Inventory db, and  2) the SOLines sub db can pull that updated POLines!ItemCost into its own ItemCost field when entering a sales Item#.   

That way an item cost change is instantly knowable by others on the network as they enter quotes and sales orders and purchase orders.   Does that make sense?

Bob,

While reading your first paragraph I was patting myself on the back, as my current QA Inventory platform does include Last Vendor, Last Cost, Last PO, Last Date, Last Qty  purchased (via overnight posting routines).
      But you left me eating dust when you shifted into a higher gear in the second paragraph and ensuing paragraphs.

Your idea of a 'standard cost' calculation every 3 or 4 months was very interesting.  I could see how that would make good sense in a manufacturing environment.  For many of our mainline inventory items, though, I unfortunately don't have that kind of elbow room luxury.  Many of the HP@ items we sell are in the 5 to 10% margin range, which doesn't leave any room for error if we want to make a profit on those repetitive sales.    As an example, effective Feb 1, HP raised their wholesale costs en masse on about 150 items an average of 5 to 8%, which takes all the cream off of an 8 - 10% profit margin.  If I waited 3 months for my pricing/invoicing to catch up, I'd be getting skinnier quick.  

I'll rescramble my design structure via your suggestions, and baby step to the next dilemma  

I've got about 15 clients for whom I've built on line Order Screens (using Excel, then converting (via SpreadsheetConverter) to a java-enabled html page, then using HTML Password Lock tool to encrypt the Order Screen for access only by that specific client.
              As you can imagine, the maintenance on keeping the Order Screens up-to-date is ridiculously tedious and time consuming (a client might have 60 or 70 items on the screen, and 20 or 30 of those items will, over a 3 or 4 month period, either go up in cost or the client will get rid of those printers and get different cartridge-using printers).
              Part of my real motivation is that I will need to offer more and more of an online presence to my clientele, and do it efficiently so that it can be profit-possible for me to do so.   I hope to get my Sesame client/server platform up and running so that I can perhaps setup a scenario where the clients come in to my network on their browser through a SSL VPN  Appliance (such as NetGear SSL312) and be presented with a screen which presents them only with a Sesame client logon screen.  They login with their specific password and are taken directly to the Order Entry screen, and this specific password has then enabled a lookup of only their specific items and pricing.  They enter their order and print the order (on my network printer!) and then leave.  
         
That method - if it's possible - eliminates almost all of the manual maintenance of a client's online access to their products and pricing.    
              
My plan B (if Plan A isn't quite doable) is for Sesame to generate HTML page reports of the clients items and pricing, and then tweak those into Order Screens and uploaded to my website.  Not quite as elegant, but better than my current mostly manual efforts.