Thank you so much. My common sense told me that just syncronizing
each replica was not enough but I could not find anything about
that. Thanks also for the info on the newsgroup.
Just to make sure I'm going in the right direction, tell me if
this is correct - I should synch each replica with the design
master, then synch them all again (with the DM)?
You shouldn't involve your DM in your regular synchronization
activity. It's your source database, the one replica that is
different from all the others. Consequently, you should squirrel it
away somewhere safe and use it only when making design changes
(i.e., changing table structures). You need to synch it with the
rest of the replica set occasionally to keep it from expiring, but
the default retention period is 1000 days. Some people seem
overeager to change that (usually because they've improperly
designed their schema and are storing temp data in replicated tables
so that the tombstone table balloons; reducing the retention period
definitely keeps the tombstone table from getting too large, but
it's the wrong solution to the problem -- many people end up having
their DM expire on them in that scenario; but I digress), but I have
never changed the default retention period on any of the many
replication projects I've done over the last 10 years.
Now, you have to decide on the topology you are going to use for
propagating your data around your replica set. The simplest, and the
easiest to implement and manage, is the star topology, where one
central replica is your hub for synchronizing, and all the other
replicas synchronize with that hub. Usually, you don't want this
synch hub to be used for editing, either, as that can cause
collisions between a synch and an edit (memo fields are particularly
susceptible to corruption if edited in bound forms using bound
textboxes, i.e., the Access default method of doing things).
So, on your server, you'd have one hub replica for synchronizing,
and one editing replica for the users on the local LAN to edit. Then
each remote user would have their own replica.
All the non-hub replicas would synch with the hub replica, which
will then always have the latest data from all the replicas that
have synched with it.
The alternative topologies all introduce more latency into the
process (multiple stars, where the hubs at the center synch with
each other, or linear, with synchs going from one to another and
back again, in a straight line), i.e., it takes more synchs to
insure that all the replicas have the most recent data.
I'm not entirely certain about Arvin's recommendation about double
synchs. I don't know what scenario in which this matters *except* if
you're propagating changes from the Design Master. That is a whole
topic on its own, so I'll stop here.
See my Jet Replication wiki:
http://dfenton.com/DFA/Replication
There are links to lots of resources there.