| title | description | author | ms.author | ms.date | ms.service | ms.subservice | ms.topic | f1_keywords | helpviewer_keywords | dev_langs | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
conflict_<schema>_<table> (Transact-SQL) |
conflict_<schema>_<table> (Transact-SQL) |
VanMSFT |
vanto |
01/15/2016 |
sql |
replication |
reference |
|
|
|
[!INCLUDE SQL Server]
The conflict_<schema>_<table> table contains information about conflicting rows in peer-to-peer replication. A conflict table exists for each replicated table in a publication, where the name of the conflict table is appended with the schema and article name. These article-specific conflict tables exist in each publication database.
For peer-to-peer replication, by default, the Distribution Agent fails when it detects a conflict. A conflict error is logged into the error log, but no conflict data is logged into the conflict table; therefore it is not available for viewing. If the Distribution Agent is allowed to continue, a conflict is logged locally on each node where it was detected. For more information, see "Handling Conflicts" in Conflict Detection in Peer-to-Peer Replication.
| Column name | Data type | Description |
|---|---|---|
| __$originator_id | int | ID of the node at which the conflicting change originated. For a list of IDs, execute sp_help_peerconflictdetection. |
| __$origin_datasource | int | Node at which the conflicting change originated. |
| __$tranid | nvarchar (40) | Log sequence number (LSN) of the conflicting change when it was applied at the __$origin_datasource. |
| __$conflict_type | int | Type of conflict, which can be one of the following values: 1: An update failed because the local row was changed by another update or it was deleted and then reinserted. 2: An update failed because the local row was already deleted. 3: A delete failed because the local row was changed by another update or it was deleted and then reinserted. 4: A delete failed because the local row was already deleted. 5: An insert failed because the local row was already inserted or it was inserted and then updated. |
| __$is_winner | bit | Indicates whether the row in this table was the winner of the conflict, which means it was applied to the local node. |
| __$pre_version | varbinary (32) | Version of the database at which the conflicting change originated. |
| __$reason_code | int | Resolution code for the conflict. Can be one of the following values: 0 1 2 For more information, see __$reason_text. |
| __$reason_text | nvarchar (720) | Resolution for the conflict. Can be one of the following values: Resolved (1) Unresolved (2) Unknown (0) |
| __$update_bitmap | varbinary( n ). Size varies depending upon content. | Bitmap that indicates which columns were updated in the case of an update-update conflict. |
| __$inserted_date | datetime | Date and time that the conflicting row was inserted into this table. |
| __$row_id | timestamp | Row version that is associated with the row that caused the conflict. |
| __$change_id | binary (8) | For a local row, this value is equal to the __$row_id of the incoming row that conflicted with the local row. This value is NULL for an incoming row. |
| <base table column names> | <base table column types> | The conflict table contains one column for each column in the base table. |
Replication Tables (Transact-SQL)
Replication Views (Transact-SQL)