Appendix D - Replication

3 4

Database replication lets users in multiple locations update data in an application while allowing design changes only in a single copy of the database. This ensures that the integrity of the database design is preserved. When a database is replicated, two or more copies of the database are created; one is the Design Master, which is the only database in which design changes can be made, and any others are replicas. You can create as many replicas as you want. The Design Master and the replicas together form a replica set, which has a unique replica set identifier.

Replicas and Synchronization

Several techniques are available for synchronizing data in Access databases, as described in the following list. Note that database synchronization is useful only when the users of the Design Master and all the replicas are connected to the same network (at least some of the time).

Briefcase replication You can use the Windows Briefcase component to keep a database up-to-date. This approach is used primarily in single-user situations in which data is taken off line on a laptop and later synchronized with the desktop database.

Database replication You can use commands on the Tools menu in Access to create and synchronize database replicas.

Replication Manager This component of Microsoft Office XP Developer is a full-featured tool for managing replicas, setting synchronization schedules, and viewing members of replica sets.

Programmatic replication Using components of the Jet and Replication Objects (JRO) object model, you can write code to compact databases, refresh data from the cache, and create and maintain replicated databases.

SQL Server replication Using a project with a SQL Server back end, the SQL Server administrator can set up replication. Users can work on data access pages off line and later synchronize them with the SQL Server database.

Replicating a Database

To replicate a database, follow these steps:

  1. Open the database to be replicated.
  2. In a multiuser situation, be sure that all users have closed the database.
  3. If the database has a database password, remove it. (See the upcoming sidebar.)
  4. Choose Tools, Replication, Create Replica.
  5. In the warning dialog box that appears (Figure D-1), click Yes.

    figure d-1.close the database to be replicated.

    Figure D-1. Close the database to be replicated.

  6. You’ll see a dialog box that asks whether you want to make a backup copy of your database before converting it to a Design Master (as shown in Figure D-2). It’s a good idea to click Yes if you haven’t already created a backup of the database.

    figure d-2.create a backup before converting a database to a design master.

    Figure D-2. Create a backup before converting a database to a Design Master.

  7. In the Location Of New Replica dialog box that appears next, you can browse for the location to which you want to save the first replica in the replica set. By default, the first replica’s name is "Replica of Databasename.mdb," but you can change it to something more meaningful, such as "Boston replica of Databasename.mdb."
  8. Click the Priority button to set the priority for the replica. The priority can be set to a value from 0 through 100. If there is a conflict during synchronization, the replica with the highest priority takes precedence.) To prevent users from deleting records in the replica, select the Prevent Deletes check box. Figure D-3 shows the replica being saved in a network folder under the name "Boston replica of Crafts 2002.mdb."

    figure d-3.save the first replica in the replica set.

    Figure D-3. Save the first replica in the replica set.

  9. Click OK. You’ll see a progress bar and then a success message, as shown in Figure D-4 .

    figure d-4.this message will appear after you create a replica.

    Figure D-4. This message will appear after you create a replica.

Removing a Database Password

To remove a database password, follow these steps:

  1. Choose File, Open.
  2. Select the file you want to open, click the arrow next to the Open button, and select Open Exclusive from the drop-down list.
  3. In the Password Required dialog box, type the database password and then click OK. (Passwords are case sensitive.)
  4. Choose Tools, Security, and then select Unset Database Password.
  5. Type your current password in the Unset Database Password dialog box and click OK.

The original database is now a Design Master. If you look at the database objects, you’ll see that the original objects all have new icons, indicating that they’re replicated objects. You’ll also see several new replication tables. (See the "Replication Reference" section later in the chapter for information on these tables.) Figure D-5 shows the Tables tab of the Crafts 2002 database Design Master.

figure d-5. here’s a design master of the crafts 2002 database with new replication tables.

Figure D-5. Here’s a Design Master of the Crafts 2002 database with new replication tables.

note


Design Masters and replicas have the same icon as regular Access databases, so before you make any changes, check the name of the database to make sure you’re working with the correct one..

After replicating a database, when you create a new object in that database, the Save As dialog box will have a Make Replicable check box (as shown in Figure D-6 ). Select the check box to make the new object replicable (so it will be replicated to the replicas); leave it unchecked to keep the object local to the Design Master database.

figure d-6. save a new table in a design master database.

Figure D-6. Save a new table in a Design Master database.

Working with a Replicated Database

You can make design changes (such as adding, deleting, or modifying database objects) only in the Design Master of a replica set; you can modify data either in the Design Master or in the replicas. As users add, change, or modify data or as the database designer changes database objects, the Design Master and the various replicas in the replica set will get out of synch.

To synchronize a database, follow these steps:

  1. Choose Tools, Replication, Synchronize Now.
  2. If any objects are open in the database a dialog box will inform you that all open objects must be closed (as shown in Figure D-7). Click Yes to close the open databases.

    figure d-7.close open databases before synchronization.

    Figure D-7. Close open databases before synchronization.

  3. The Synchronize dialog box will appear next (as shown in Figure D-8), with the name of the single replica in this replica set selected. You can use the Browse button to select another replica if the replica set has more than one replica.

    figure d-8.select a replica for synchronization.

    Figure D-8. Select a replica for synchronization.

  4. Click OK to start synchronizing. A dialog box will appear warning you that the database must be closed prior to synchronization; click Yes to close the database and continue.
  5. You’ll see a progress bar indicating the progress of the synchronization, and then you should see the success message shown in Figure D-99.

    figure d-9.this message should appear after you synchronize a replica.

    Figure D-9. This message should appear after you synchronize a replica.

Most of the time, Access will successfully resolve replication conflicts using the priority numbers assigned to members of the replica set. However, if you don’t receive the success message shown in the figure, you should check for synchronization errors to find out what went wrong. To check for synchronization errors, choose Tools, Replication, Resolve Conflicts to open the Conflict Viewer.

Replication Reference

When you replicate an Access database, a number of changes are made to the database. These changes are visible only if you’ve checked the System Objects check box on the View tab in the Options dialog box. The fields listed in Table D-1 are added to the tables, and the tables listed in Table D-2 are added to the database. The properties listed in Table D-3 might also be added to the database.

Table D-1. New replication fields

Field Description

s_GUID

A globally unique identifier (GUID) for each record

s_Lineage

A binary field that contains information about the history of changes to each record

s_ColLineage

A binary field that contains information about the history of changes to each field

s_Generation

A field that stores information regarding groups of changes

The information in these fields can’t be changed.

An additional field named Gen_Fieldname will be added for each Memo or OLE Object field in the database.

A number of tables are added to a database when it is replicated. The most significant of these tables are listed in Table D-2.

Table D-2. Replication tables

Table Description

MSysSideTables

A table used to store information about conflicts between the user’s replica and another replica in the replica set. This table isn’t replicated. It’s supplied for information only, and its contents can be modified or deleted by custom conflict-resolution routines or by the user. All side tables are named table _conflict, where table is the original name of the table. (This table exists only if conflicts have occurred.)

MSysSchemaProb

A table that is present only when an error has occurred while the design of a replica is being updated. It provides additional details about the cause of the error. This is a local table and isn’t replicated.

MSysReplicas

A table that stores details, such as the Replica ID and path, of all known replicas in the replica set. This table appears in all members of the replica set, but it is not replicated.

MSysTranspAddress

A table that stores addressing information for the Synchronizer and defines the set of synchronizers known to this replica set. This replicated table appears in all members of the replica set.

MSysTombstone

A table that stores information about deleted records and allows deletions to be dispersed to other replicas during the synchronization process. This table appears in all members of the replica set, but it is not a replicated table.

MSysRepInfo

A table that stores information about the entire replica set, including the identity (GUID) of the Design Master. The table contains a single record. This replicated table appears in all members of the replica set.

MSysExchangeLog

A table that stores information about replica synchronizations that have taken place. It is a local table and isn’t replicated.

The information in these tables (except for MSysSideTables) can’t be changed.

Table D-3. Replication properties

Property Description

Replicable or ReplicableBool

A database or object property. When the property is set to T (or to True for ReplicableBool), the database, table, or query is replicable. The Replicable and ReplicableBool properties can be used interchangeably.

KeepLocal

A property appended to a table or query. When the property is set to T, the object should not be replicated when the database is replicated. An object that is already replicated can’t have its KeepLocal property set to T.

ReplicaID

A property that provides each member of the replica set with unique identification. This property is read-only and is stored in the MSysReplicas system table.

DesignMasterID

The ReplicaID of the Design Master. It is stored in the MSysRepInfo system table as SchemaMaster.

ColumnLevelTracking

A database or table property. When the property is set to True (the default), conflicts are tracked at the column level of a table.

note


The Replicable and KeepLocal properties apply only to tables and queries. This is because other database objects (such as forms, reports, macros, and modules) are either all replicated or all local. Only tables and queries can be set to replicable or local individually.

When a database is replicated, any incremental AutoNumber fields in the tables will be changed to random numbering. Existing records will keep their values, but new records will have random AutoNumber values.



Microsoft Access Version 2002 Inside Out
Microsoft Access Version 2002 Inside Out (Inside Out (Microsoft))
ISBN: 0735612838
EAN: 2147483647
Year: 2005
Pages: 172
Authors: Helen Feddema

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net