When you design your replication system, you should also consider the following restrictions.
Adaptive Server and Replication Server system tables cannot be copied during normal replication. However, the execution of supported commands and system procedures on certain system tables can be copied in warm standby applications. Refer to “What information is replicated?” on page 65 in the Replication Server Administration Guide Volume 2 for more information. In addition, some data is automatically copied between RSSDs in the replication system.
Tables that you want to copy must have unique primary keys.
Client applications should not update unique index or primary key columns in a way that a key could duplicate the key of another row. Because of the way Replication Server copies transactions, this type of update could result in duplicate rows or errors at replicate databases.
For example, if pk_col is the primary key column for table1, the following command could cause errors or incorrect data at the replicate database:
update table1 set pk_col = pk_col + 1
If there is a primary key or unique index constraint on the replicate table, the updates fail and the DSI thread for the replicate database is suspended.
If a trigger is associated with a replicate table, do not put a commit statement inside the trigger. Triggers that contain commit statements at replicate sites may cause a duplicate key and make Replication Server recovery fail.
Replication Servers of different versions can work together in the same replication system, but certain features may be restricted. See “Mixed-version replication systems” for more information.
Virtual computed columns cannot be replicated since Replication Agent cannot forward virtual columns to Replication Server, and Replication Server cannot insert or update virtual columns.
