Choosing a Resolver
When choosing a resolver, you need to consider the importance of conflict resolution in your replication application and whether you will need to build a custom resolver.
If your data is partitioned without multiple users writing to the same partitions, and your replication topology is relatively basic (one Publisher and a few Subscribers), conflicts should be rare or nonexistent. In these environments, you may not need a complex conflict resolution strategy. A strategy using the default settings for conflict resolution, using local Subscribers and a first change in wins policy, is recommended.
Another factor is determining whether to build a custom resolver or use the default merge conflict resolver. Using a custom resolver is the recommended option if your business needs require a more finely tuned solution than is available with the default resolver, and the table associated with the custom resolver is relatively stable, or updating the custom resolver is not an issue.
Choosing whether to use the default resolver, or a custom resolver and the logic used in a custom resolver, should be based on the data. For example, suppose the employees entering customer-ranking data into a set of nonpartitioned replicas span various job categories (branch managers, line managers, sales staff), and job category determines whose data should be given priority. In this case, a custom resolver can be built that uses job category data from the article to determine the priority winner when a conflict occurs.
Custom resolvers are usually specific to a particular table; if the table used in the article is modified (for example, renaming the column name that is used in conflict resolution), the custom resolver may have to be modified and recompiled.
If conflicts are likely to occur with some frequency, here are the most important decisions you will need to consider when implementing a conflict resolution strategy.
| Conflict Resolution Issue | Recommendation |
|---|---|
| Different categories of users require different priority values. |
|
| First change in wins conflict solution wanted. | Use the default merge resolver and create local Subscribers. |
| Multiple users changing the same data row acceptable, as long as no conflicting changes made to the same column. | Use either the default merge resolver or a custom resolver with column-level tracking enabled. |
| Flag multiple changes to any value in a row as a conflict. | Use either the default merge resolver or a custom resolver with row-level tracking. |
| Conflict outcome data needs to be different from original conflict data. | Use a custom resolver that calculates new values. Alternatively, optionally use the stored procedure resolver and write a custom procedure that returns a result set that contains the new data. |