View Single Post
  #7  
Old April 23rd, 2010, 07:36 PM posted to microsoft.public.access.tablesdbdesign
Steve[_77_]
external usenet poster
 
Posts: 1,017
Default Design for future merging

I have merged remote databases into a master central database many times.
The key is to append the data in higher level tables from the remote
database into the the corresponding higher level table in the master
database. This assigns a value for the primary key in the master table. Then
append the data in lower level tables from the remote database into the the
corresponding lower level table in the master database. Now you need to
update the foreign key in the lower level tables to the value of the
corresponding primary key in the master table. I would like to offer to
automate your database to be able to do this. I will charge a reasonable fee
depending on the number of tables and relationships in your database. If you
want my help, contact me.

Steve





"Rlong via AccessMonster.com" u58125@uwe wrote in message
news:a6ee3a8f8ad28@uwe...
I've created a small but somewhat complex relational database that uses
autonumber fields in higher level tables as primary keys to link with
foreign
keys in lower level tables. At this point I have up to 5 levels of tables.
I'd like to copy this database for use at 4 other remote sites, with the
ultimate intention of merging all 5 back together after a few months of
data
entry. I've read quite a bit about how to merge databases that weren't
originally designed with future merges in mind, and this ends up being
quite
complex with so many levels and autonumber-dependent tables. I'm wondering
if
there is a way that I can create the duplicate databases from the outset
that
would make future merging easier?

For instance, by causing the autonumbers at each different site to either
start at a particular point (e.g., one site be the 100000s and another the
200000s), or, by using the "random" setting for autonumber such that no
two
autonumbers in the same table were identical (although my sense is that
"random" introduces its own problems).

Any thoughts on how to make the future merge easier would be helpful.

Thanks

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...esign/201004/1