-Snip
>Nay I am also supposed to maintain the master tables common, esp. the Items Master as it will have a Bill-Of-Material attached to the items. BOM once created is suppose to be used in all, incl. the parent company. So any changes to the BOM will reflect in the all the companies.

If it's not just reporting, it's an entirely different ballgame.

Personally I'd consider merging all these DB's into one and adding KeyField CompanyId, Int, as Identity where applicable.

Once that's done you can:

A. Build your reporting views, not in VFP but at the backend, thus letting the server do most of the work.

B. Build VFP remote views to facilitate updates.

If you already have a VFP interface you could pass the companyname as a parameter at startup, declare the parameter as public and in your VFP
remote views add:

Select...Where...And Table.CompanyId = ?gcCompany

As to your fears about DB size, again I don't know FireBird, but SQL Server handles very, very large DB's efficiently. I've had tables with literally millions of records and responsetime in the miliseconds.

>
>>If you have a unique identifier for the various subsidiaries, you could load all your subsidiaries into one new DB, and if you don't, you could still use this approach and create one during load.
>
>I was thinking of putting all of them together in one sinlge database identifying from which company the data came from. But what fears me is the size of data between all of the companies may become big and then may raise issue in speed.