ryetee.
I assumed you had two discrete database with the same named tables.
What I do is drop all linked tables, and then recreate the links to the new backend. Some people do the same process by using "refreshlinks".
Personally in your case I would not have differently named tables. I would have two or more discrete backend databases, one for each company each with the same named tables.
Alternatively use the docman's idea of having a company flag. However, if you use the company flag, then you may need to change a fair bit of functionality to work differently.
----
I suppose you could do it your way by renaming tables within the database. I haven't got time to post now, but I will come back to it later today.
I've got this more or less working although on the face of it it looks cumbersome but I can live with that.
WHat I have is....
Country A
Front End A, Back End A
Country B
Front End B, Back End B, Copy Back End A, Local Update Back End B!!
Why you ask!! OK so each country works on it's own back end. At given intervals Back End A is copied over to country B. Within Front End B all the completed jobs from this copied Back End A will be effectively exported to the Local Update Back End B which can be worked on in country B. there is a good reason to do this believe me!
All the back ends are identical structures with identical names. The data is obviously different. In the front end of country B I link to Back End B for day to day processing (with the same linked table name as the table name itself). At some point a new copy of the Back End from A is copied over. The tables for this are linked to with a different name (table name with a prefix to identify this). It is at this stage I want the original tables linking to the Local Update Back End B to a) copy over data and b) so that data can be worked on. On exiting this part of the system the tables are linked back to the original database (Back End B).
Clear as mud I know but it works.