Best Practices

From Jet Replication Wiki -- Microsoft Office Access Replication

Jump to: navigation, search

Contents

Create dropbox on the local machine

When using indirect replication, you may be tempted to create all the dropboxes for all your remote replicas in a single location; after all, you might think the dropboxes would be easier to manage by consolidating them in a single location. It's a bad idea: you should always create the dropbox on the same computer where the synchronizer is running. Furthermore, you should create the dropbox in the root folder of a local hard drive (e.g., C:\dropbox or D:\dropbox).

Consider how one synchronizer communicates with another remote synchronizer during a synchronization event. It opens the local MDB file, determines the changes to be applied, and packages those changes into a small message file in the dropbox of the remote synchronizer. If the communication link is faulty and it is unable to communicate with the remote dropbox, then the synchronizer will respond immediately and will try again in the future. Once it has successfully created the message file in the remote dropbox, the remote synchronizer sees the message file in its own dropbox, which is on its local drive, and proceeds to process the file.

On the other hand, if you had consolidated the dropboxes into a single location, then the remote dropbox would need to reach communicate over the wire to open the file. If the communication link was faulty, the message file could become corrupted, but the sending synchronizer would be unaware of the communication breakdown. It would not re-create the message file. Therefore, creating dropboxes on the local disk of each synchronizer adds some fault-tolerance to the replication system.


Split the database

Contrary to the Microsoft documentation, replication is not appropriate to use for forms, reports, and other application objects. It is only appropriate to use for tables and queries, which rightly belong in the backend of a split application. Splitting a Microsoft database into separate frontend (application) and backend (data) components is always good practice, but it is vital for a replicated database. Replication is used to propogate data changes between the various replicas while some other (perhaps manual) method is used to distribute changes to the frontend database. Tony Toews wrote a comprehensive discussion about splitting the database at http://www.granite.ab.ca/access/splitapp/index.htm He also wrote a system for distributing new versions of the frontend at http://www.granite.ab.ca/access/autofe.htm


Never move a production replica

Every replica in a replica set has a unique identifier that records the computer name and file path (name) where the MDB file is located. If you ever move and open the file, then the Jet database engine (i.e., Access) will realize that the file has been moved and will assign it a new ID number. This action is completely invisible to you.

The previous ID number is lost – it cannot be recovered, yet it remains in the list of replicas in the replica set. Thus you have created a dead replica. If ever you delete some records from a table, they will be held in a hidden table, waiting to communicate with the dead replica. Of course, that will never happen, and you database is consigned to carrying these tombstone records forever more. If you move the file several times, you will create several dead replicas, and the problem becomes compounded.

Any moving method is forbidden: floppy disk, email, ftp, USB disk. No moves are allowed (the only exception is to use the Replication Manager software which contains special provisions to move the file safely.)

If you are creating a legitimate new replica, then it is allowable to copy the file by whatever means necessary, provided you do not open the file until it reaches its final location. Once you have placed the file into its final location, then it is safe to open the file with Jet (Access) because the original file remains in its original location and the new copy will receive a new, legitimate ID number.


Use a hub computer for centralized synchronization

Place a replica from the replica set on a standalone computer on the network that your users connect to. This hub replica should run the Replication Manager software if you use Indirect replication, or it could simply be in a shared folder if you use Direct replication (say, for occasionally-connected laptop users). This hub should be distinct from the local copy of the database that your local users connect to across the LAN.

This practice is virtually mandatory when using Indirect replication, because the synchronizer software must run full time in the foreground of a Windows computer. Most network administrators will not allow the synchronizer to be installed on a server, and its not a good idea to install it on a regular, in-use, desktop machine, either. The synchronizer belongs on its own computer, and that is where the hub replica should be, too.


Never edit the hub replica directly

If you create a synchronizing hub, complete with own replica and distinct from all in-service replicas, then you can be assured that it will never introduce any user-created replication errors into your system. Its sole purpose is to be a conduit between all the other replicas, and you will never need to suspect it as a source of data errors. Therefore, do not edit the hub replica directly. Use it only for synchronization.


Do not share the replicas on an Indirect hub

If you use indirect replication, then the replica managed by the synchronizer must be invisible to the network. In other words, the replica must be in a non-shared folder. If the folder was visible to the network, then any other synchronizer would be able to see it, and would synchronize directly, thus defeating the purpose of the indirect synchronization. The only way to prevent two synchronizers from synchronizing directly is to ensure that their managed replicas are invisible to one another. Therefore, do not place replicas that are managed by any synchronizer into shared folders. Of course, the dropbox folder must be shared, but not the folder where the managed replicas reside.


Use a replica farm

If you use Indirect synchronization, then you should create multiple replicas on the hub, and manage them all with the synchronizer. This multiple-replica configuration is known as a replica farm. A replica farm provides a measure of self-healing into the system. Suppose there was only one replica; if the synchronizer decided it was unfit to use for synchronizing, then the link would fail. But if there was more than one replica, then it would simply switch to using a different replica, and the link would continue unabated. Furthermore, the synchronizer can revive the failed replica without manual intervention.


Preserve and protect the Design Master

Every replica set has one Design Master where you apply any design changes. This should be the sole purpose of the Design Master; it should not be part of your production database. Keep it on a hidden folder away from all the production replicas, but synchronize with it periodically to prevent it from going stale.

If you want to experiment with design changes, then copy the design master to a temporary folder and use it from there. You will need to promote it to Design Master status, but once you have settled on your design changes, write them on a piece of paper and delete the temporary copy. Then apply the design changes to the real Design Master. By following this procedure, you will not introduce dead replicas into the system, and you will not corrupt or introduce unneccessary changes into your Design Master.

Personal tools