To make replicas of your database, you first convert it to a Design Master. The Design Master becomes the first replica of the new replica set. As you make additional replicas from the Design Master, they are added to the set. You can have only one Design Master in a replica set. If you want to make changes to the tables, queries, forms, reports, macros, or modules, you make those changes in the Design Master. This prevents users at multiple replicas from making conflicting changes to the database’s design and objects.
You can convert a database to a Design Master in one of three ways:
Important If you protect a database with a database password, you can’t sychronize replicas of that database. Before you begin using replication, remove any database password protection from the database. Setting permissions with Microsoft Access security does not interfere with synchronization. In addition, replicated objects retain the permissions that you give them in the Design Master.
If you want to customize your replication system, you can use DAO to replicate your database.
Û To replicate a database by using DAO
"T".Important Before you use the KeepLocal and ReplicableBool properties, create and append them to the Properties collection of the object. If you try to refer to these properties in your code before you create and append them, a run-time error occurs. For TableDef and QueryDef objects, you create and append the property to the object’s Properties collection. For forms, reports, macros, and modules, you create and append the properties to the Properties collection of the Document object that represents the database object.
When you convert a database to a Design Master, all of the objects in the database are converted to objects you can replicate. If you don’t want all objects in your database copied throughout the replica set, you can append and set the KeepLocal property on any objects you don’t want replicated. You must do this before you convert the database to a Design Master. For example, if your database has a table that contains confidential personnel information, such as salaries, you can set that table’s KeepLocal property to "T" to keep it local while all other objects are replicated.
Note The object on which you are setting the KeepLocal property may have already inherited that property from another object. However, the value set by the other object has no affect on the behavior of the object you want to keep local—you must directly set the property for each object.
If you try to set the KeepLocal property and the property has not already been appended or inherited, you get an error. The following example sets the KeepLocal property to "T" and includes an error handler in case the “Property does not exist” error occurs. If called, the error handler both appends and sets the property.
Sub SetKeepLocal(objParent As Object)
Const errPropNotFound = 3270
On Error GoTo KeepLocalPropHndlr
objParent.Properties("KeepLocal").Value = "T"
Exit Sub
KeepLocalPropHndlr:
If (Err = errPropNotFound) Then
' Create and append the KeepLocal property if it does
' not already exist.
objParent.Properties.Append _
objParent.CreateProperty("KeepLocal", dbText, "T")
Else
GoSub UserDefinedErrorHandler
End If
Resume Next
End Sub
If you have defined a relationship with enforced referential integrity between two tables in your database, set the KeepLocal property to the same value for both tables. If the property value is not the same for both tables, the conversion fails. You can’t set the KeepLocal property while the relationship is in effect. Before you set the property, remove the relationship between the tables. After you set the KeepLocal property, define the relationship between the two tables again and proceed with converting the database.
After you convert a database to a Design Master, all new objects created in the Design Master replica, or in any other replica in the set, are treated as local objects. Local objects remain in the replica where they’re created and are not copied throughout the replica set. Each time you make a new replica in the set, all of the objects in the source replica that can be replicated are included in that new replica, but none of the local objects are included.
A database that can have replicas containing both replicated and local objects is much more useful because users can share corporate, division, or workgroup data that is common to all their tasks, while maintaining location-specific data and custom queries and reports.
If you create a new object in a replica and want to replicate it so that all users can use it, import the object to or create it in the Design Master, and set the object’s ReplicableBool property to True in your code. You can also set the ReplicableBool property by selecting the Replicable check box in the object’s property sheet. Any local objects in other replicas in the set that have the same name as the newly replicated object are renamed to objectname_Local during the next synchronization. The next time you synchronize, the newly replicated object appears in the other replicas in the set.
Tip To open an object’s property sheet, right-click the object in the Database window, and then click Properties on the shortcut menu.
Similarly, if there is an object that can be replicated and you want to make it local, set its ReplicableBool property to False in your code. You can also set the ReplicableBool property by clearing the Replicable check box in the object’s property sheet.
Caution When you change the setting of the object’s ReplicableBool property from True to False, the Microsoft Jet database engine deletes the object from all replicas in the replica set except the Design Master. Even if you temporarily set the ReplicableBool property to False in the Design Master and then set it to True again, the next synchronization deletes and re-creates the table in each replica. Unless you synchronize all replicas before you make the design change, you lose any data entered in the table in a replica since the last synchronization.