If you mean that 2 companies will each be using a separate copy of the same database solution then you will need to manually make changes in both places - doing double the work... UNLESS you have the option of making the changes in one, then saving a clone and importing the data from the second into that clone.
Neither of these is a pretty solution.
Yes, 2 companies will be using seperate copies of the same database solution.
I have a similar situation except it is 2 companies being run out of the same office. It is a ROYAL PITA... every little change made in one needs to be redone in the other. To compound the problem, once in a while there is something to be done in just one place... Then later when I need to make a "double" change it sometimes needs to be handled slightly differently.
If I get it in my mind that this is really 2 clients under one roof it doesn't make me SO crazy.
If you can't share the file, then the situation you have is not dissimilar to what commercial developers have to face. There are 2 popular methods, but both require someone to do a reasonable amount of work to make it easy at your end.
One method is to use the "Separation Method", this is where the interface sits in one file and the data sits in another. Most of the time, all that is required is to replace the old interface file and upload the new. It's usually 'most of the time', but this method doesn't really cater for schema changes in the data file.
The other method as Marks says, is to distribute a clone of the file with the changes and that should have a script to automate the importation of the data. It's probably the more popular method now. If you do this yourself, version control is critical.
I just remembered, there is a better way to do the second method, and that is to use a tool like Goya's RefreshFM which not only automates the import, it also gives you full statistics on what was imported, any missing fields etc, it also automatically sets the serial numbers. You can find more information and a demo copy at www.goya.com.au. BTW, I'm not affiliated with them in any way.
Of course, in all cases the receiving side should not be able to make any changes or they would be lost.
Someone has to decide that there will only be one source of database changes/development. If it's done centrally there is control. If every bugger and his dog is changing the database then - well good luck!