When synchronization occurs after the initial synchronization, changes made to data on one subscriber might conflict with changes made on a different subscriber or on the Publisher. When you create the publication, you assign a resolver to handle these conflicts.
When synchronization occurs, the Merge Agent that is running on the Publisher detects any data conflicts, and then determines which data is accepted and propagated to other sites based on the resolver associated with the publication.
Microsoft SQL Server Compact 3.5 supports both row-level and column-level tracking when synchronizing with SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2 Publishers.
Synchronization with SQL Server 2000 is not supported in SQL Server Compact 3.5.
After a conflict is detected, the Merge Agent launches the conflict resolver that is selected for the article. This might be the default resolver, one of the other supplied resolvers, or a custom resolver. The accepted changes are chosen according to the rules of the conflict resolver. SQL Server Compact 3.5 Subscriber conflicts are always detected, resolved, and logged at the Publisher.
Multiuser access now permits data changes during synchronization. These changes can cause a client-side conflict. Client-side conflicts are detected, but not resolved, at the Subscriber. The conflict will be redetected and resolved at the publisher during the next synchronization. For more information, see Multiuser Access and Synchronization.
Resolvers can use the source of the data change, or the priority value of the Subscriber, to resolve conflicts. For example, the default resolver follows the rule that the changes on the Publisher always override changes on the Subscriber. You can opt to use a different resolver that always favors the changes on the Subscriber over those on the Publisher.
SQL Server Compact 3.5 clients always have a priority value of 0. Therefore, a resolver based on priority value will not give priority to the changes made on the device.
For more information about conflict detection and resolution, see "Merge Replication Conflict Detection and Resolution" in SQL Server Books Online.
Stored procedure based merge conflict resolvers are not supported by SQL Server Compact 3.5 subscriptions.
Custom Resolvers let add business logic to Replication. A custom resolver is a DLL built in either managed or native code. To be used, the custom resolver must be registered on the Publisher and the server running IIS by using the stored procedure sp_registercustomeresolver. The sp_registercustomeresolver stored procedure includes the is_dotnet_assemblyparameter, which you set to true for a resolver built in managed code, or false for a native DLL.
A custom resolver must be registered on the computer that is running IIS in addition to the computer that is running SQL Server.