Re: Replication question

Brad,

The issue you're having is that those are, as far as the data engine, different records, since they have different IDs. Remember, it's the primary key that determines the uniqueness of a record, all the rest of the fields are just window-dressing.

So in architecting a replicated model, you need to always ask whether duplicates can be entered, and if so, how you're going to catch and deal with them. In the case of Branch Locations, in most cases this is a pretty stable list; I'd be tempted to pre-populate it, and then restrict who can add to the table. After all, Head Office decides to add branches, data entry operators don't. But if that's not feasible (or in other cases where it isn't) you have to rely on a primary key that has semantic meaning...branch name, perhaps, rather than using an autokey.

HTH

• Rebecca.

Bradley J. Gong wrote in message <35a23ee5.536090_at_nntp1.ba.best.com>...
>In Access 8.0, how "smart" is the replication feature? For example,
>if you've got a relationship between two tables, say tblPeople and
>tblBranchLocations, where tblPeople contains a foreign key,
>BranchLocationID. If a remote user (using Replica1) adds a few people
>into tblPeople, but at one point, has to add a person that works at a
>brand new BranchLocation. The BranchLocation gets added to
>tblBranchLocations, receiving a new BranchLocationID because it is an
>AutoNumber field.
>
>At the same time, a different remote user (using Replica2) adds a few
>people, some of which work at the same new location, but which is not
>yet in their replicated table. So, they add the same "new"
>BranchLocation to tblBranchLocations and tie that BranchLocationID to
>the person's record.
>
>When the remote users submit their replicas at to the administrator
>for synchronization, it looks like tblBranchLocations has BOTH new
>entries (one from Replica1, and one from Replica2) people records
>pointing to each. Obviously, this could cause problems!!! It doesn't
>appear that is what the Resolve Conflicts option is for. In the quick
>test that I ran to create this example, Access didn't see any
>conflicts to resolve.
>
>Can this issue be handled more appropriately? What design
>considerations should be made when dealing with replication?
>
>Please CC any replies via email.
>
>Thanks!!
>-- Brad
><bradg_at_thincsolutns.com>
><http://www.thincsolutns.com>
Received on Wed Jul 08 1998 - 00:00:00 CEST