Questions on replica types and priorities

I have a few questions regarding properly setting replica types and
priorities when creating a replica set that I hope someone can help with.
The intended setup of the replica set is to have a design master as a global
replica, a hub as a global replica, and local replicas on notebooks.  The
notebook replicas do not need to sync with each other, so I plan on
assigning them all the same priority, and assigning the hub a higher
priority than the laptop replicas.  The design master will be synced with
the hub only as needed (when there are design changes or <1000 days from the
last sync, whichever comes first).  The hub will sync with the laptops, but
only in one direction - they will get data from the hub but not send the hub
any data.  This is because the laptop replicas are backends used only for
lookup information (job, employee, etc. information that changes on a daily
basis).

Where my confusion comes in is in setting the priority of the design master.
I assumed that I should set it to 100 and the hub at 90.  But, what happens
in the following scenario:

1) The hub is created from the design master (which has no data at this
point), and the laptop replicas are created from the hub
2) The hub's data is updated on a nightly basis and the laptop replicas get
that data when the user syncs, which could be anywhere from every day to
once a week
3) A year after the hub is created, I have design changes that I need to
implement (a field is added to a table)

At this point, I sync the hub with the design master.  The design master
sends its structural changes to the hub, and the hub sends its data changes
to the design master.  I am understanding this correctly.

Thanks,

Tony

"Tony" <|toxendine@hoopercorp.com|> wrote

Avoid local and anonymous replicas:

Sometimes it does not pay to be anonymous!
http://trigeminal.com/usenet/usenet027.asp?1033

The key problem with them:

the local and anonymous replicas are only able to sync with a
single replica -- their hub. If their hub fails for some reason,
then they are permanently cut off from the replica set, forever.

That's all I need to know in order to decide that I will never use
local or anonymous replicas -- my data is way too value for that!


If they are not being edited, it will not matter if you do a two-way
synch, right?


If the DM has priority 100, the hub would have priority 90 (90% of
the DM's priority), and the replicas created from it would have
priority 81 (90% of 90).


Yes.

I am not sure why you are worrying about replica priority in a case
where edits are happening only in the hub. Replica priority is
important for resolving conflicts -- all other things being equal,
the replica with the lower priority loses the conflict (but you are
still notified of it with the conflict resolver and given the
opportunity to reverse Jet's default resolution). But if you are
pushing edits out in one direction only, this is not relevant, since
there will never be any conflicts between the replicas in the field
and the hub. And given that there are no replicas other than the DM,
and you are properly using the DM for nothing but design changes
(i.e., you never edit its data), there is never any possibility of
conflicts.

Now, I think your priority topology is exactly right, as it is
precisely what I use in all my replicated apps. But you do not need
it. Well, except that some day you may need to start editing in the
field, and at that point you have the right replica priorities in
place and do not need to recreate your replica set (even though you
can change the ReplicaPriority property in an existing replica, it
never gets updated in MSysReplicas, so it does not do any good; thus,
the only way to set the replica priority is to create a replica,
either using the Access UI, which will create the replicas with 90%
of the parent's priority, or in DAO, where you can set the priority
to any arbitrary number between 0 and 100).

I strongly urge you to use full replicas, not local replicas. Should
your hub replica be damaged and need to be replaced, your replicas
will all be orphaned and unable to synch.

I'd also recommend a replica farm as your hub, rather than a single
hub replica:

http://trigeminal.com/usenet/usenet006.asp?1033

This provides you with maximum protection against something going
wrong. Experience tells me that no matter how carefully you plan,
something *will* go wrong, and you want as many replicas with
identical data as possible.

David,As always, thanks for the feedback. Based on this:1) Our laptop

David,

As always, thanks for the feedback.  Based on this:

1) Our laptop replicas should be made global, not local, replicas
2) A replica farm should be implemented, using 2 or more replicas created
from the design master

I have been using TSI Synchronizer and see that I should be able to set up the
replicas within the farm to sync with one another on a scheduled basis.  At
this point, my laptop replicas are coded such that the end-user will click a
button that is hard coded to sync with a specific replica (the hub).  If I
set up the farm replication correctly, is it wise to leave hard coded
reference in or is there a better way to do things?  It seems as though if I
leave the synchronization code pointed to a specific database, I lose
flexibility.

Thanks again,

Tony

"Tony" <|toxendine@hoopercorp.com|> wrote

I would say so. I see no real advantage to local replicas. Anonymous
replicas have the advantage of being completely disposable, so you
might use them to ship data between two sites, but you would not want
an edited replica to be anonymous.


You can create them by copying the hub replica, too.


To get the real advantage of a replica farm, you would  need to be using
indirect replication, and you would  then synch with the hub
synchronizer, which would choose which particular replica you
actually synched with.


Yes, you do. But since you are not using indirect replication, you
could not get the advantage of it anyway. If you were using indirect
replication, you would not be able to choose the partner replica at
all, only the synchronizer.

--
David W. Fenton                  http://www.dfenton.com/
usenet at dfenton dot com    http://www.dfenton.com/DFA/

David,Thanks again for the reply.

David,

Thanks again for the reply.  Under this scenario, I will have at least two hub
replicas.  I have got my sync code set up such that if a laptop cannot sync
with one of the replicas, it will try to sync with the other (I tested this
by misnaming one of the hub replicas as I refer to it in code).  Do you
think it makes sense to repopulate only one of the hub replicas during an
overnight process then sync the other hub replicas with this one?  My
concern is that, if the initial hub replica does not get repopulated, the
others will not either.  I doubt that this will happen, but want to make sure
that I am covering all my bases.  Also, is there a best practice as to how
many replicas should be in a farm?

Thanks,

Tony

"Tony" <|toxendine@hoopercorp.

I have not actually used a replica farm. I do usually have a hub
replica for synching and a production replica for editing, so the
hub replica is 1-replica replica farm. I almost always set up my
Access apps to have a backup replica on each laptop, so that is
another 1-replica "farm." The point is that I hardly ever have a
machine with just 1 replica, and I make sure the main replica synchs
with the other replica on a regular basis (in an Access app, usually
at shutdown).

I do not know what is reasonable for a real replica farm. I'd think
that 3 replicas total should suffice. I'd have one be the hub and
the other two be the "farm." In the absence of indirect replication,
I'd schedule a synch, and do all the synching from remote with the
one designated the hub. I do not think I'd automatically let it fall
over to another replica, as there can be many reasons why a synch
with a particular replica would fail, and a synch failure would by
our coal mine's canary. If it just fails silently and moves onto the
other replica, you are depending on somebody reporting it to you. If
they cannot complete their synch, they are more likely to report, I
think. And then you can investigate it and recover from the problem,
whatever it might turn out to be.

Or so it seems to me.

--
David W. Fenton                  http://www.dfenton.com/
usenet at dfenton dot com    http://www.dfenton.com/DFA/

David,Thanks for the reply.

David,

Thanks for the reply.  I am gad I asked the question - I like the idea of
having a second replica on the laptop and the suggestion to sync the
production replica with the backup replica on shutting down the app.  The
'silent' failover I will keep in place, because I can determine if the sync
failed on the first attempt, fire off an e-mail from the laptop to me, and
allow the laptop to sync with the second hub replica without involving user
input.  I am also logging the date/time/type of sync in a table in the
laptop's FE; between this and the e-mail, I should be able to diagnose the
issue.  One of my challenges is that this app is going to be used by
non-technical users who are likely to dismiss error dialogs without
reporting them.  This way, I can gather that information without requiring
their input, something that we have done for a while and has proven to be
solid.

Thanks again for all your help.  I still have a lot to learn in this arena,
but with your assistance I have learned quite a bit over the past few months.

Tony