>>Why have multiple databases? If you have multiple databases, then you have to manage the changing between them based on Company. I would add a field (companyid) to each table record key for the tables that are shared between the companies; i.e., the record key is now comprised of multiple fields (id and companyid). This key field will separate the records by company. Tables that are shared across companies; i.e., lookup tables, do not have the company key (unless each company can have a different configured list of values). Then create a custom property on _VFP as follows:
>>
>>

>>ADDPROPERTY(_VFP, "CompanyId", "")
>>

>>
>>Now set this property value for the current company. Then use this property value in the SELECT statements to retrieve the records that are applicable to the current selected company. This same functionality is used in SAP R/3 and S/4HANA to separate between client systems and has worked very well for decades.
>
>Your solution would work, but it aggregates everything into a single source.
>
>I prefer encapsulation. I prefer smaller indexes and data sets. I prefer data isolation, giving one the ability to do backups on those data sources not in use at any time, along with a particular version being copied to another folder for a trial month-end close or year-end rollover, and so on.

I choose to use separate databases as my customers like to be sure their data cannot be accidentally accessed by another company. So for security each company gets their own folder and copy of the database with security limiting access to that company only. It also has the benefit of smaller tables sizes etc.

In PostgreSQL I use a separate schema for each company for the same reasons.

Simon