Working with schema changes

This topic applies to ArcGIS for Desktop Standard and ArcGIS for Desktop Advanced only.

When a replica is created, data and schema are copied from the parent geodatabase to the child geodatabase. The data includes the rows to be replicated from the datasets in the replica. The schema consists of the fields, domains, subtypes, and other properties that describe the replicated data.

Initially, the schemas are identical on both replicas, but over time, changes might be applied to each replica schema. For example, one replica may require additional fields to complete a project, while the relative replica may need to apply a new domain to an existing field. When this happens, the schemas of the replicas are no longer the same.

The following has been provided to work with schema differences in replicas:

Maintaining schema differences—You can choose to allow replicas to make schema changes independently of one another. Geodatabase replication is designed to permit most schema differences between replicas, allowing data synchronization to continue to work in most cases.

Whenever you apply a schema change to one replica but not the other, you should anticipate the following issues:

Applying schema changes across replicas—Modifying the schema of a replica to match the schema of a relative replica is a completely separate process from data synchronization. Three tools are provided for this purpose: Compare Replica Schema, Import Replica Schema, and Export Replica Schema. The tools are available on the Distributed Geodatabase toolbar in ArcMap, the Distributed Geodatabase pull-right menu in the Catalog tree, and as geoprocessing tools.

The tools are used in a two-step process that involves first running the Compare Replica Schema tool to generate an XML file containing the schema changes, then importing these changes with the Import Replica Schema tool. If you're working in a disconnected environment, you first need to run the Export Replica Schema tool to export the schema with the changes to an XML file. This file can then be transported on media such as CDs or DVDs for input into the Compare Replica Schema tool.

The following is a list of schema changes and whether or not they can be applied:

Add

Change

Drop

Field

Y

Y (domains)

Y

Domain

Y

Y

Y

Table/Feature Class

Y

Y (domains, add/drop fields)

Y

Geometric network

N

N

Y

Topology

N

N

Y

Feature dataset

N

N

Y

Relationship class

N

Y (add/drop fields, domains)

Y

This table describes the schema changes that may be done on replicated datasets.

Adding a feature class or table to a replica cannot be accomplished with the tools discussed above. Instead, you need to run ArcObjects code. View a sample of this code

Removing data from a replica—A list of the datasets involved in each replica is stored in a replica geodatabase. If you delete one of these datasets, a warning is displayed. If you choose to continue with the deletion, the dataset is removed from the replica dataset list. You can add data back to a replica using the ArcObjects API. Also note the following:

Identifying schema differencesIf you want to closely monitor schema changes, you can use the tools to compare replica schemas to identify differences. The Import Replica Schema wizard lists the schema differences.

Best practices

In general, it is best to avoid schema changes. Schema changes can lead to inconsistencies among replicas, and the extra task of applying schema changes can increase performance costs. However, there are cases when schema changes must be applied.

The following outlines best practices for working with schema changes:

  1. Lock down the system—Make sure that people using the system are working with the appropriate permissions. It may be necessary to write applications that prevent certain types of unplanned schema changes, such as adding or dropping a column.
  2. Apply periodic schema comparisons—Since replication is fault tolerant, systems that perform synchronizations will most likely not be interrupted by schema changes. However, a good practice is to periodically run a schema comparison to ensure that unplanned schema changes have not been applied.
  3. Don't synchronize until completing a maintenance task—It is sometimes necessary to apply temporary schema changes to complete a maintenance task. For example, some organizations require that a geometric network be removed, unversioned, then rebuilt and re-versioned. Until the network is re-versioned, data synchronization will fail.
  4. Apply systemwide schema changes—If schema changes need to be applied, apply them systemwide and in an organized manner. For example, you may want to use a top down approach where the changes are applied at the root replica and propagated downward.
Schema changes
7/30/2013