Access 2003 Synchronization

[Guest]

I have timidly replicated my first database and I have two replicas. (Both
the Design Master and the replicas are on a network drive.)

I've successfully synchronized the DM and the replicas but I'm not sure I'm
doing it correctly.

Do I have to synch the DM with each replica, then synch the two replicas, or
what? I'm afraid I'm not going to have all the data in each place.

Thanks for any help.

 

[Arvin Meyer [MVP]]

If you have multiple replicas, you must sync all but the last one twice to
have all databases match. Remember too, that you should only replicate the
data (back-end of a split database) to avoid corruption problems. Your best
bet for replication answers is the Microsoft.public.access.replication
newsgroup.

 

[Guest]

Arvin,

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)?

Joanne

 

[David W. Fenton]

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.

 

[Guest]

Dave,

In a couple of minutes you've told me what I've been searching for for quite
a while. I'm not near as experienced as you are so I really appreciate your
advice and suggestions.

At this moment I have a design master and only two replicas. I don't expect
to have many more than 5 at any time soon. But, I do like your idea of the
hub replica and saving the DM for design master. I'll feel safer that way!!

Thank you very much.

This thread is closed as far as I'm concerned.

 

[Arvin Meyer [MVP]]

in
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.

The purpose of the double-sync (except for the last replica to sync) is to
make sure all replicas have the same data. In a star hub the server first
syncs with replica 1, then replica 2 ... replica n

Replica 1 never sees anything from replica 2 unless it's sync'd a second
time. The only replica that gets it all is replica n (the last one) unless
the others are sync'd a second time. Then they are all the same.

Incidently, great replication wiki/FAQ, I'll be refering replication
questions there.

 

[Jeff Conrad [MSFT]]

David,

Do you mind if I include a link to your Wiki on my Replication section here?
http://www.accessmvp.com/JConrad/accessjunkie/resources.html#Replication

--
Jeff Conrad - Access Junkie - MVP Alumni
SDET - XAS Services - Microsoft Corporation

Co-author - Microsoft Office Access 2007 Inside Out
Presenter - Microsoft Access 2007 Essentials
http://www.accessmvp.com/JConrad/accessjunkie.html
Access 2007 Info: http://www.AccessJunkie.com

 

[David W. Fenton]

This thread is closed as far as I'm concerned.

You will find the newsgroup microsoft.public.access.replication to
be quite helpful for replication questions. Though right now I'm
about the only active person answering questions, but the archives
are especially useful because Michael Kaplan used to answer all the
questions posted there, and he was the biggest expert on Jet
replication there has ever been (I can't hold a candle to him in
terms of depth of expertise). He moved on to internationalization
and now works for MS.

 

[David W. Fenton]

The purpose of the double-sync (except for the last replica to
sync) is to make sure all replicas have the same data. In a star
hub the server first syncs with replica 1, then replica 2 ...
replica n

But when would you do that? It's like laundry -- you may do all your
laundry, but that night when you take off your clothes, you've got
more dirty laundry.

With a star topology, your replica is identical with the hub at the
center of the star after any synch with it. That, I think is the
best you can ask for.

There's one exception, though, and that's if you have any conflicts.
After resolving conflicts you should definitely synch again so that
your resolutions filter through ASAP to the other replicas.

Of course, with Jet 3.x, you saw conflicts only in the replicas
between which the conflicts occurred. In Jet 4, you see them in all
replicas. Because of that, with Jet 4, it's better to have one admin
user resolving all conflicts, seems to me.

But no well-designed replicated app should be having many conflicts,
so if you have lots of them, you should rethink your application's
architecture.

Replica 1 never sees anything from replica 2 unless it's sync'd a
second time. The only replica that gets it all is replica n (the
last one) unless the others are sync'd a second time. Then they
are all the same.

Until they all take off their clothes and go to bed.

Or something.

Incidently, great replication wiki/FAQ, I'll be refering
replication questions there.

Please sign up for an account and add your own two bits -- so far,
nobody has provided content but me, and that means it's *very*
incomplete.

http://dfenton.com/DFA/Replication/

 

[David W. Fenton]

Do you mind if I include a link to your Wiki on my Replication
section here?
http://www.accessmvp.com/JConrad/accessjunkie/resources.html#Replic
ation

Not at all!

I also wouldn't mind if you signed up for an account and added ideas
of your own. You don't have to answer questions. You can create
topics and then somebody (me or someone else) can come along and
fill in the information later.

So far, other than spammers, I'm the only one who has added content!
I always wanted it to be a collaborative effort (which is the point
of a wiki!).

 

[Arvin Meyer [MVP]]

Please sign up for an account and add your own two bits -- so far,
nobody has provided content but me, and that means it's *very*
incomplete.

http://dfenton.com/DFA/Replication/

You and Michael have far more experience in Replication. My 2¢ is closer to
1¢

 

[David W. Fenton]

You and Michael have far more experience in Replication. My 2¢ is
closer to 1¢

But that's not the point -- I need people to flesh out topics that
need to be addressed, and that would include both people who know
replication well and those who don't.

And there are topics that you could write up. For instance, DAO is a
link in several of the articles, but I haven't yet written the
article that defines what it is. Anybody who understands DAO could
flesh that out and explain what it is. I'd then go in and edit it
and add the replication-specific content for the subject.

Have you ever participated in editing a wiki? It's really quite an
amazing experience -- it can go in so many different directions, and
almost anything is allowed.