Quote Originally Posted by Ianv View Post
Chris,
There is absolutely no need to have a Tenant ID in any table which is a child of Customer unless you want to re-use ID's between Tenants.
Look at the Table structures in the WebOrderMobile Example.
You will see that the OrdHea table has a relationship to Customer.
Now look at OrdDtl. It has a relationship to OrdHea but absolutely no mention of Customer. Nevertheless, OrderDtl records are unique to a Customer because their parent OrdHea is related to Customer. A multi-tenant application simply has another level in this relationship: Tenant. Now a Customer will relate to Tenant and all the child tables should stay as is.

There are some other factors you need to take into account in a a multi-tenant application.

Users need to belong to a Tenant so WebAppUser will need to include a Tenant ID.
SessionManager.wo needs to be modified to have a Tenant DD so that the right Tenant is found on Login
If Table ID's are duplicated between Tenants then the system counters can no longer reside in a simple System table like Ordsys
Other Tables such as Vendor, Invt, etc. will also need a Tenant ID with appropriate changes to selection lists etc. I believe in real life SalesP records are better belonging to a Customer than a Tenant but that's up to you.
Every View using Tables which are children of Tenant will need a Tenant DD

I'm sure there are other things but the important thing is to get the concept and it will all follow on from there.

I would recommend that you make a copy of the WebOrderMobile workspace, add a Tenant Table to it and Tenant ID fields to the Tables that need them including OrdHea with a 2 segment index TenantID/Order_Number This does not need to relate to Tenant. It simply serves to make Order_Number non-unique.
Modify SessionManager.wo to have a Tenant DD populated on Login.
Create two Tenants
Manually add Tenant ID 1 to all the Table with a Tenant ID
Write some code to copy all the relevant tables changing Tenant ID to 2 wherever it appears.
Now you will have a multi-tenant application where you can login to a single Tenant and view its orders. You will then need to do a bit of work to manage Table ID's so you can create new orders.

Once you have done the above, you should have a good understanding of how to develop a Multi-Tenant application.
Good luck,
Ian
Thank you Ian for sticking with me on this. I believe we are saying the same thing. I do understand the design of multi-tenancy in a single DB. And that was my point exactly. That for any table to have re-used ID's across different tenants, they must have a tenant column as part of the primary key to make them unique and for children to point to them (requiring a mult-part foreign key). And that is the situation I have and I would think most people would have. If any of my customers say "Why can't I have an invoice 1000?" I don't want the answer to be "because someone else who happens to be in the same system as you already has it". I agree the system of assigning IDs must take tenant into account and I am already doing that.

We have drifted from my original topic of manual table relating as is so often the case Multi-tenancy handling was just one aspect of manual relating and I have been trying to dispense with manual tracking of parent/child in favor of local DD relations or other more native methods. I have used the prior postings in this forum on manual relation handling (and the Discovering Dataflex book) and have had some success.

I was still hoping for some summary or cheat sheet that we can turn to to make sure to cover all the bases when manually handling relates in DDOs and even how DEOs may need to be altered.

/Chris K.