Working with schema changes

This topic applies to ArcEditor and ArcInfo 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:

• Edits that don't synchronize—Data synchronization only imports changes for tables and fields that are common to both replicas. If an edit is made to a field that is not in the relative replica, it will not be applied when importing changes. Another example is when a geometric network is dropped on one replica but not the other. When this happens, the orphan junction class is removed and, therefore, changes from the relative orphan junction class are not applied.
• Invalid values—Changes that violate domains, subtypes, connectivity rules, and relationship rules are applied when synchronizing changes. The validation tools on the editor can be used to check the newly imported values.
• Data synchronization errors—These can happen when you manually make a schema change to both replicas. For example, you may want to add a field to a table. If you do this, be sure to make the exact same schema change in all cases. If there is a difference (for example, a field is a string on one replica but an integer in the other), a data synchronization error will occur.
• Unsupported changes—Some types of schema changes can cause synchronization to fail, but no warning is displayed if you make the change. These changes are not detectable by the geodatabase replication system. They include database-level operations like changing permissions on tables in the database. If permissions are changed to read-only for replicated data, a failure will happen when trying to import changes from the relative replica.

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:

• If you drop a table or feature class and want to add it back to the replica, you must run code to do so. Simply re-creating it does not work.
• If you drop a geometric network or topology, you can't add it back to the replica. The replicas will still synchronize; however, synchronizing topology exceptions are not supported, and you also can't synchronize changes made to the orphan junction class.
• Dropping a feature dataset and adding the classes back to the replica has no effect.
• You can't drop relationship classes and add them back to the replica.

Identifying schema differences—If 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.