There are several restrictions when you design a replication system.
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. See Replication Server Administration Guide Volume 2 > What information is replicated for ASE warm standby application? 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.
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.
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.
When replicating encrypted columns which have:
Domain rules or check constraints defined on the columns, Replication Server bypasses the domain rules or check constraints for insert and update statements.
Access rules defined on the columns, Replication Server returns the 2929 error—“The access rule cannot be attached”—when processing update, delete, or select statements.