These Adaptive Server operations may cause incorrect replication:
Using truncate table on a primary table does not truncate replicated tables because the operation is not logged.
Disabling the secondary truncation point with dbcc settrunc and then truncating the log can cause lost transactions.
Replication Server does not support nested transactions within replicated stored procedures.
When you enable replication for a stored procedure using sp_setrepproc or sp_setreplicate, Adaptive Server always runs the stored procedure within a transaction. If you have not explicitly run the replicated stored procedure within a transaction, Adaptive Server places an implicit begin transaction command at the start of the procedure.
If the replicated stored procedure contains nested transaction commands such as begin transaction, commit transaction, or rollback transaction, you might get errors when you run the procedure. For example, a rollback transaction command rolls back to the start of the stored procedure, rather than to the nested begin transaction command, which was the intended rollback point.
Data that is inserted into a primary table using an unlogged bulk copy operation is not replicated.
In a database, you cannot replicate multiple tables that have the same name but different owners. For example, if a database contains two tables dbo.authors and user3.authors, Replication Server distributes only one of them.
Sybase recommends that you make the database owner own all tables in the primary database, and that you make the database owner or maintenance user own all tables in the replicate database. If the database owner or maintenance user does not own the table in the replicate database, use user-defined function strings for insert, update, and delete operations.
To use the atomic method of subscription materialization:
The user who enters the create subscription command or the database owner must own the primary table. Alternatively, you must use user-defined function strings for select operations at the primary database.
If the database owner or maintenance user does not own the replicate table, use user-defined function strings for select operations at the replicate database. If the owner of the replicate table is different from the owner of the primary table, create a unique function string by using a distinct function-string class.
Ensure that client applications do not update primary key columns in multiple rows of a replicated table such that a key duplicates the key of another row. Such duplication might cause errors in the replicate database.
For example, if pcol is the primary key for the reptbl table, this command might cause errors or incorrect data in the replicate database:
update reptbl set pcol = pcol + 1
This table shows before and after values for pcol at the primary database if reptbl has three rows with pcol values 1, 2, and 3.
Before |
After |
---|---|
1 |
2 |
2 |
3 |
3 |
4 |
RepAgent retrieves the log records and submits the records to Replication Server using commands equivalent to:
update reptbl set pcol = 2 where pcol = 1 update reptbl set pcol = 3 where pcol = 2 update reptbl set pcol = 4 where pcol = 3
Replication Server treats each row as an independent update, so the first row is updated three times and the second row is updated twice. If there is a unique index on the table, the additional updates cause errors in the replicate databases. If there is no unique index on the replicate table, duplicate rows result as shown below.
Before |
After |
---|---|
1 |
4 |
2 |
4 |
3 |
4 |