In order for replication to work correctly, the database schema in the source database must be compatible with the schema in the target database.
Note In order to avoid schema compatibility issues, it is recommended that you use exactly the same schema for both source and target tables.
Schema compatibility means that, for any table included in the source partition, the following statements are true:
▪ the corresponding table with the same full name, including schema and catalog names, exists in the target partition,
▪ the target table has all the columns that exist in the source table,
▪ the target table has defaults for any columns that do not exist in the source table, or those columns can contain null values,
▪ column types in the target table are similar or less restrictive than the column types in the source table (for example, SMALLINT data always fits in INTEGER columns and shorter VARCHAR data fits into longer VARCHAR columns). Data conversions are supported according to ODBC conversion rules (for example. INTEGER values are converted to VARCHARS).
▪ primary key, foreign key, unique index constraints, check conditions, and triggers must not prevent data from being replicated into, or deleted from, the target database.
If replication hits an error related to schema incompatibility, replication from the incompatible source is aborted.
If a schema update is required and the schema change might create a temporary schema incompatibility, replication might terminate with error. In this case, it is recommended that you stop replication explicitly by using the STOP REPLICATION statement, execute the schema update on both source and target databases, and then restart replication with the START REPLICATION statement. When replication restarts, all the related database schemas that are used in replication are refreshed.