Merge replication with Microsoft SQL Server Compact 3.5 follows this process:
Data is published on SQL Server.
Subscriptions to the publications are created.
Data at the Subscriber is updated.
Data is synchronized.
The following table defines some of the terms used in this section.
A database table that is enabled for replication.
A collection of articles.
A specific set of rows or columns in a publication.
A database that makes a publication available through replication.
A database that receives replicated data and can pass data changes back to the Publisher.
A request for a copy of the publication to be delivered to the Subscriber.
A database that receives articles published by a Publisher.
Publications specify what data is published. Publications are typically customized to different users or groups of users. Sometimes, all users need the same data. For example, every employee might need a copy of the company employee directory. In other cases, different groups of users need different partitions of data. For example, sales representatives might need one set of data, while customer support technicians need a different set of data. Individuals might also need data specifically filtered for them. A sales representative, for example, might need only the data for his or her own customer accounts.
When you create the publication, you specify what articles it contains. Although SQL Server publications might contain other database objects, such as stored procedures, views, and user-defined functions, SQL Server Compact 3.5 replication ignores these objects and only includes tables in the SQL Server Compact 3.5 subscription. You can specify which of the rows and columns are included in the article through filtering. For more information, see "Replication" in SQL Server Books Online.
After you define the publication, an application subscribes to it either programmatically on the device, by calling the methods revealed by the SQL Server Compact 3.5 Replication object or the SqlCeReplication class, or by using the New Subscription Wizard in SQL Server Management Studio. When the subscription is created, the initial snapshot from the Distributor is applied at the subscription database on the Subscriber.
Your application likely updates the Subscription database. Merge replication permits each subscription database to be updated autonomously. Updates can occur whether or not the device is connected to the network. Each SQL Server Compact 3.5 database uses change tracking to keep track of INSERT, UPDATE, and DELETE statements made at the SQL Server Compact 3.5 Subscriber. Both row-level and column-level tracking can be used.
Typically, users connect the device to the network intermittently. These connections permit the application to synchronize changes made at the Subscriber with changes made at the Publisher. The application initiates synchronization by calling the synchronization methods revealed by the Replication object or the SqlCeReplication class. Synchronization is a four-step process.
Extract changes and create the input message file.
The SQL Server Compact 3.5 Client Agent extracts all inserted, updated, and deleted records from the subscription database at the SQL Server Compact 3.5 Subscriber and propagates them to the SQL Server Compact 3.5 Server Agent through HTTP. The SQL Server Compact 3.5 Server Agent creates a new input message file and writes into that file the insert, update, and delete changes sent by the SQL Server Compact 3.5 Client Agent.
Run the SQL Server Reconciler process and apply changes to the publication database.
When all requests have been written to the input message file, the SQL Server Compact 3.5 Server Agent initiates the SQL Server Reconciler. The SQL Server Reconciler loads the SQL Server Compact 3.5 Replication Provider, which reads the input message file and informs the SQL Server Reconciler of changes made to the SQL Server Compact 3.5 subscription database that must be applied to the publication database at the Publisher. During processing, the SQL Server Reconciler detects and resolves conflicts. A conflict occurs when more than one Subscriber or Publisher updates the same record.
The SQL Server Reconciler resolves conflicts with conflict resolvers. You can use the conflict resolvers provided with SQL Server to implement simple conflict resolution for your SQL Server Compact 3.5 replication applications, or you can write custom conflict resolvers to implement more sophisticated solutions. For more information, see Replication Conflict Detection and Resolution.
Create the output message file.
The SQL Server Reconciler informs the SQL Server Compact 3.5 Replication Provider of changes made at the Publisher that must be applied to the subscription database on the device. The SQL Server Compact 3.5 Replication Provider writes these changes to an output message file on the server running IIS.
Read the output message file and apply changes to the SQL Server Compact 3.5 subscription database.
When the SQL Server Reconciler process is complete, the SQL Server Compact 3.5 Server Agent locates the output message file created by the SQL Server Compact 3.5 Replication Provider. This file contains the changes that have occurred at the Publisher and that must be applied to the subscription database on the device. The SQL Server Compact 3.5 Server Agent reads the output message file and transmits it to the SQL Server Compact 3.5 Client Agent on the device. The SQL Server Compact 3.5 Client Agent applies the changes from the output message file to the SQL Server Compact 3.5 subscription database.
The SQL Server Compact 3.5 Client Agent processes both the input and output message files in logical blocks as it reads from, or applies changes to, the subscription database on the device. By processing each message file in this way, the SQL Server Compact 3.5 Client Agent avoids writing the whole message file on the device, conserving storage space on the device.
After the SQL Server Compact 3.5 Client Agent has incorporated all changes into the subscription database on the device and any conflicts have been resolved, the publication and subscription databases are synchronized and data is converged. However, because updates can occur continuously, data values might not be the same at the Publisher and at the Subscribers.
You cannot start two merge replication processes at the same time on the same database.