[AccessD] Database Replication

I haven't gone that far, but I did get as far as 75 replicas and had no
trouble. To be perfectly accurate, the 75 replicas were in four branch
offices, each of which had a central replica on a server, then synchronized
with all the branch replicas. At HQ the server replica synchronized with the
four branch offices. The system worked perfectly without so much as a hiccup
in over a year, at which point, through no fault of the replication stuff,
we moved to SQL Server.

If you want to hang 200 replicas off a single HQ replica, I would put the
synchronizer on a machine running little or nothing else, and similarly for
the HQ replica. Both of these machines should be considered 365/24 machines.
The master replica can reside on your friend's development machine and be
manually synchronized with the HQ replica, so s/he can make changes without
immediately broadcasting them until s/he is ready to do so.

Incidentally, I first went down this road after replicating to just the main
servers in the branches. But then I realized that using replicas on all the
local PCs was a terrific way to cut down the net traffic inherent in typical
FE/BE scenarios (combo and listbox contents being copied down the wire over
and over again, etc.).

When you pause to consider the amount of data actually communicated during a
synchronization, it's tiny -- a few k in both directions if the
syncrhonization is relatively frequent. How many rows can even a really fast
typist enter in 5 minutes? And in a well normalized database, most of the
values will be ints or dates or money, with a few text fields here and
there, so what does that add up to? Not much.

hth,
Arthur

On 3/17/08, Doris Manning <mikedorism at verizon.net> wrote:
>
> Does anyone know if there is a limit to the number of replication copies
> that Access can handle merging back together?
>
>
>
> A friend of mine is looking at the potential of over 200+ replicated
> copies
> that will need to be merged back together and was wondering if this was
> going to be a problem.  This is for a federal government project that he
> doesn't have much "developmental" control over but he'd like to throw on
> any
> possible breaks before the development team gets too far down the road if
> they are going in a lousy direction.
>
>
>
> Doris Manning
>
> Database Administrator
>
> Hargrove Inc.
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>