Conditions and Limitations for Replication Server Support for Transfer Object Ownership

There several conditions and limitations for replication of objects affected by a transfer of object ownership.

Owner status – if you use sp_setreptable to set the owner status for a primary table to:
- owner_on – and subsequently there is a change in table owner, you must immediately make the corresponding change in affected replication definitions.
- owner_off – and subsequently there is a change in table owner, do not make the corresponding change in affected replication definitions. Otherwise, the replication definition filters out all transactions for the table, resulting in no data replication.
DDL replication – you must ensure that Replication Server can replicate DDL commands before you execute alter... modify owner and rs_send_repserver_cmd.
Suppose you set owner_on but you do not enable DDL replication by setting sp_setreptostandby to none for warm standby systems, or by setting set replication to off for non-warm standby replication. Assuming that you do not make corresponding changes to the table replication definition, any change you make with alter…modify owner at the primary database does not replicate. As a result, the table owner of the affected table at the primary database is different from the owner of the replicate table. Therefore, data cannot replicate to the replicate table.
Suppose you also alter the table replication definition to change the owner at the:
- Primary and replicate tables with:
```
alter replication definition replication_definition_name
alter owner from old_owner to new_owner
```
  Replication Server forms SQL statements to replicate to new_owner.table_name which does not exist since the actual replicate table owner name was not changed. This causes an error in the replication process that suspends the DSI thread and the connection to the replicate database. You can then modify the table owner in the replicate database and resume the connection. Replication continues normally without data loss.
- Primary table with:
```
alter replication definition replication_definition_name
alter primary owner from old_owner to new_owner
```
  Replication Server receives data for replication from the primary table that is owner-qualified as new_owner.table_name and replicates these changes to the old_owner.table_name replicate table.
Warning! Data replication loss can result if you have an incorrect assumption about the status of DDL replication in your replication environment and alter your replication definitions incorrectly. Understand your replication environment before you make changes to replication definitions affected by changes to object ownership.
Different table owners – Replication Server does not map tables owners from a primary owner to a different replicate owner
Different table names – when you create replication definitions, you can specify table names at the replicate database that are different from the table names at the primary database:
```
create replication definition replication_definition_name
with primary at data_server.databasew
with primary table named table_owner1.pri_table
with replicate table named table_owner1.rep_table
```
If there is a requirement for a transfer of object ownership, execute alter…modify owner at the primary database and then at the replicate database. Immediately after executing alter…modify owner, execute the rs_send_repserver_cmd stored procedure at the primary database or change the replication definition to modify the table names in the affected replication definition.
However, replication fails if there is any data in the queue where tables have the old owner. To ensure that there is no data loss during replication, either:
- Drain the queue before changing the owner of the replicate table, or
- After changing the table owner, allow the DSI to suspend if the primary table receives new data and then execute rs_send_repserver_cmd
Same table with multiple projections of the same replication definition – you can create multiple replication definitions for the same primary table and customize each one, called a projection, so each replication definition projection can be subscribed to by a replicate table whose characteristics are different from those of the primary table and other replicate tables. The other projections can replicate the same table using a subset of the commands or to a different replicate table.
After a transfer of object ownership at the primary table, if you use rs_send_repserver_cmd with alter replication definition or alter replication definition by itself to modify the:
- Primary table owner – Replication Server only modifies the primary table owner of the replication definition you specified.
- Primary and replicate table owner – Replication Server modifies both the primary and replicate table owner of the replication definition you specified.
Replication Server modifies all replication defintions and projectons if you use the wildcard "*" instead of replication definition name. If modifying a replication definition causes the replication definition and a projection to be identical, Replication Server does not proceed with the modification and returns an error instead.
Mixed-version support – Replication Server does not allow you to change table ownership in a replication definition or database replication definition if there is a route to a replicate Replication Server with a route version earlier than 15.5
Impact on HVAR and MSA – high-volume adaptive replication (HVAR) and multisite availability (MSA) cache replication definitions during processing. If you transfer object ownership for a table and modify the affected replication definitions, you must invalidate the cached replication definition by disabling HVAR for the table or by stopping MSA.