Working with schema changes(ArcInfo and ArcEditor only)
Release 9.3 Last modified April 2, 2009	Print all topics in : "Managing Distributed Data"

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:

• Data Loss—Data synchronization will only import 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.
  
• Applying Changes Inconsistently—You may decide to manually make the same schema change to all replicas. For example, you may want to add a field to a table. If you do this, make 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), data synchronization will error.
  
• 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—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

• If you drop a table or feature class and then want to add it back to the replica, you must run code to do so. Simply re-creating it will 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 doesn't affect anything.
  


• You can't drop relationship classes and then add them back to the replica.
  

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.

Please visit the Feedback page to comment or give suggestions on ArcGIS Desktop Help.
Copyright © Environmental Systems Research Institute, Inc.