Article ID: 248434
Article Last Modified on 3/14/2006
APPLIES TO
- Microsoft SQL Server 7.0 Standard Edition
This article was previously published under Q248434
BUG #: 57098(SQLBUG_70)
SYMPTOMS
Replication lineage can become invalid when performing non-conflicting column updates on the subscriber.
The Merge Agent detects conflicts through a system column called lineage, which represents the history of changes in a row. When the lineage become invalid it may manifest as metadata mismatch and/or erroneous conflicts and can lead to missing or invalid rows after a merge operation takes place.
Following is an example of an erroneous metadata mismatch conflict error that may occur:
For more details, see the SQL Server Books Online topic, "How to view and further resolve synchronization conflicts (Enterprise Manager)" or "conflict reporting".
NOTE: If you are using alternate conflict resolution mechanisms be sure to check any associated logging facilities to ensure they are operating correctly or provide extended conflict information.
STATUS
Microsoft has confirmed this to be a problem in SQL Server 7.0. This problem has been corrected in U.S. Service Pack 2 for Microsoft SQL Server 7.0. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
254561 INF: How to Obtain Service Pack 2 for Microsoft SQL Server 7.0 and Microsoft Data Engine (MSDE) 1.0
For more information, contact your primary support provider.
MORE INFORMATION
There are several ways the conflicts can be resolved priority based, custom procedures, COM object, and others. If you receive a message or indication that conflicts occurred during the merge process and you suspect that data has not been merged properly the "Replication Conflict Viewer" is the easiest way to detect how the conflict occurred and how it was resolved. Using the utility you can observe reported conflicts. Using the following details you can determine if the reported conflict was erroneous due to the lineage mismatch.
The Merge Agent detects conflicts through a system column named lineage in MSmerge_contents, which represents the history of changes in a row. The agent updates the lineage column in MSmerge_contents automatically when a user updates a row.
The entry is a combination of a site identifier and the last version of the row created by that site. When the Merge Agent is merging changes, and it encounters a row that might have changed recently, it examines the lineage of each site's version of the row to determine if there is a conflict. When conflicts occur, the agent initiates an automatic reconciliation.
Conflicts to the data in the base table can be recognized either at the column level or at the row level. The default option presented through the user interface is column-tracked articles. This option allows changes made to disjointed columns to be merged; only changes made to the same columns are flagged as conflicts.
The issue is with the former of the two column level operations. The row was modified at the subscriber but the same columns were not affected at other participating sites at the time of the merge operation. The result is no need to combine the row changes and or perform conflict resolution.
The conflicts can be reported at the publisher, centralized, or subscriber, decentralized, based on the setup of conflict logging in the replication topology.
The conflict resolver stores information about the conflict by creating a conflict table named conflict_usertablename. The conflict table has the same structure as the original table, and the conflict resolver copies the "losing" version of the row into the conflict table.
To determine if you are encountering this issue you can compare the columns in the row from the losing version to the data in the actual table to see if the criteria for this issue is met and only disjointed columns where merged.
We keep track of the conflicts (counts) in the publisher_conflictcount and subscriber_conflictcount columns in sysmerge_history. One has to read the conflict_tablename to identify the rows involved in conflicts. However, sysmerge_history can be queried to identify if a conflict has occurred.
Keywords: kbbug kbfix KB248434
