Working with schema changes (ArcInfo and ArcEditor only)

Working with schema changes (ArcInfo and ArcEditor only)
Release 9.3

• 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.

• 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.

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.