Hi,

We are planning a system that will run in multiple locations, with a copy of the database at each location. Most tables will only be able to be updated at Headquarters. Changes will be exported from headquarters and imported at the multiple remote locations.

Remote locations will only be able to enter new payment entries. These new entries will be exported and then imported at headquarters.

Normally files in the remote locations will only be updated by importing and exporting, but we can see that someday the user will want to just copy the entire HQ database to the remote location.

I think we've got most details worked out (assigning unique primary keys, knowing what has been exported, etc.).

But we're having trouble coming up with a "fool proof" method of determining each location's identity. We can't put it in a table in the database (in case it is ever copied in it's entirety).

So we thought of a free table named something like Config##, where ## identifies the remote location. There will be a Config00 at HQ, and it can be copied to the remote location, but will be ignored if another Config## is found. We're still working out the details.

Can anyone shed any light on a good/better way to handle this? TIA, j