ArcGIS Server Banner

Working with schema changes (ArcInfo and ArcEditor only)

Working with schema changes (ArcInfo and ArcEditor only)

Release 9.3 E-mail This TopicPrintable VersionGive Us feedback

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 may 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:

Fault Tolerance—Geodatabase replication is designed to be tolerant of most schema changes. This means that even if each replica makes schema changes, data synchronization will still execute successfully.

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

Applying schema changes—Tools are provided to apply schema changes across replicas. The process involves comparing the schemas of the data in each replica and getting the differences. For some of these differences, you can choose to modify the schema of a replica's data to match the relative replica. Applying schema changes is a completely separate process from data synchronization.

Schema changes can be applied in both a connected and a disconnected environment. In a connected environment, you can compare the schemas directly. In a disconnected environment, you need to export the schema of one of the replicas to a replica schema file. This file can then be transported on media such as CDs or DVDs and compared to the relative replica.

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

Notes on schema changes

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 delete, the dataset is removed from the replica dataset list. You can add data back to a replica using the ArcObjects API.

The tools provided allow you to choose how best to manage schema changes on replicated data. Since the system is fault tolerant, you can choose to allow the replicas to make schema changes independently from one another. Even with schema differences, data synchronization will work in most cases. If you want to closely monitor schema changes, you can use the tools to compare replica schemas before importing data changes.

Working with schema changes

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 add 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 and then rebuilt and reversioned. Until the network is reversioned, data synchronization will fail.

    4. Apply systemwide schema changes—If schema changes need to be applied, apply the changes 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 down.

Schema changes

See Also

  • About synchronization
  • Applying schema changes