On 3 Aug 2006 12:43:51 -0700, "Matt" <martino165[ at ]hotmail.com> wrote:
[Quoted Text] >I have a split DB with the FE residing on user's desktops and linking
>to the BE located on a server. The FE shortcut targets a specific
>security workgroup file located in the same place as the BE. So far
>this has remained fairly local, geographically and therefore server
>connection speed has not been an issue at all.
>
>Now.. The database is being migrated to a national server (located
>offsite) and will be accessed by twice as many people. When I move the
>BE to the new server and link up, the speed is very slow. I have
>deployed some methods of keep the .ldb file active and tried to
>maximize the efficiency of the db, but the bottleneck appears to be the
>network.
>
>I have only sparse knowledge of sync and replication. I was hoping
>someone could provide som good insight as to options for this type of
>situation.
>
>I was thinking of possible duplicating the BE and place one down here
>on a local server and one on the national server, which would be
>considered local to all of the other users. I would then need to
>sychronize and both BEs to update the data that has been inputted.
>There shouldn't be any design changes to the BE, but with expanding
>users further customization may be needed and therefore methods for
>having a master BE local to me that would sync the data but override
>and update any design or structural changes.
>
>Thoughts?
>
>Thanks in advance....
David Fenton has replied with an option about using Terminal Server.
If you are able to implement TS, I think that is a good way to go.
However, if TS is not an option for you for whatever reason, there are
some pointers about replication that you should bear in mind:
- only replicate the BE. The FE should be distributed via some other
means. See http://www.granite.ab.ca/access/autofe.htm
- purchase the Office Developer's Kit (or whatever it is called. For
A2003 this is the Access Developers Edition contained within Visual
Studio Tools for Office.) so that you have Replication Manager. RM is
a software for managing Indirect Synchronizations between locations.
Indirect Sync is the only reliable method for synchronizing over a
WAN. Do NOT attempt to sync using direct synchronization (which you
would be forced to do if you did not have the RM software). See
http://www.granite.ab.ca/access/developereditionfaq.htm
- establish a "replica farm" at each end of the sync. These farms
consist of several replicas managed by the same synchronizer, and they
provide a "self-repair" mechanism that improves the reliability of
cross-WAN syncs. See www.trigeminal.com for additional information
about farms.
- establish a "production replica" at each end for you users to
interact with on an everyday basis. The production replica is sync'd
periodically with the replica farm. Keeping the users out of the
replica farm for their production work improves reliability.
- isolate your Design Master from the automatic synchronizations. You
should sync your DM periodically to keep it from going "stale" (the
default period is 1000 days, so it's not a huge effort), or whenever
you make a schema change.
- never move a replica from its designated location except by using
Replication Manager. Moving a replica, say via Windows Explorer, will
result in the creation of a dead replica that will eventually clog
your system.
Hope this helps
--
jackmacMACdonald[ at ]telusTELUS.net
remove uppercase letters for true email
http://www.geocities.com/jacksonmacd/ for info on MS Access security
|