The following Adaptive Server operations may cause incorrect replicated data:
Using the truncate table command on a primary table does not truncate replicated tables, because the operation is not logged.
Disabling the secondary truncation point with the dbcc settrunc command and then truncating the log can result in lost transactions at replicate databases.
Replication Server does not support nested transactions within replicated stored procedures.
When replication is enabled for a stored procedure using sp_setrepproc or sp_setreplicate, Adaptive Server always executes the stored procedure within a transaction. If you have not explicitly executed the replicated stored procedure within a transaction, Adaptive Server places an implicit begin transaction at the start of the procedure.
If the replicated stored procedure contains nested transaction commands, such as begin transaction, commit transaction, or rollback transaction, errors may result when you execute 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 that was the intended rollback point.
Data inserted into a primary table using an unlogged bulk copy 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 can distribute 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, or 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.
Client applications should not update the primary-key columns in multiple rows of a replicated table in such a way that a key can duplicate the key of another row. This may result in duplicate rows or errors at replicate databases.
For example, if pcol is the primary key for the reptbl table, the following command may cause errors or incorrect data at the replicate database:
update reptbl set pcol = pcol + 1
The following 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 to Replication Server commands equivalent to the following:
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 that the first and second rows are updated three and two times, respectively. If there is a unique index on the table, the additional updates cause errors at 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 |
