Whenever you synchronize two members of a replica set, there is always the possibility of conflict between versions because the same record might have been updated at both locations. During synchronization, if Microsoft Jet detects that the same record was changed in both members, Microsoft Jet treats it as a synchronization conflict even if the changes made in one replica set member were in different fields than the changes made in the other member.
When a synchronization conflict occurs, Microsoft Jet does not attempt to resolve the conflict based on the content of the records or the changes made to the data. Instead, it uses a simple algorithm to select one of the record versions to be the official change and writes the data from the other record version into a conflict table. It is then the responsibility of the programmer, database administrator, user, or a custom resolution program to review each conflict to determine whether the correct information was applied to the database.
The algorithm Microsoft Jet uses to select one record version over the other is based on the record’s version number, which is stored in the table’s s_Lineage field. Each time a change is made to the data in a record, the version number increases by 1. For example, a record with no changes has a version number of 0. A change to data updates the version number to 1. A second change to the same data, or a change to different data in the record, changes the version number to 2. If the record in one replica set member has been changed once and the same record in the second member has been changed three times, the record in the second member has a higher version number than the record in the first member. When Microsoft Jet compares the version numbers for the same record, it assumes that the version that has changed the most is the more correct of the two versions. If both records have the same version number, Microsoft Jet examines the value of the ReplicaID property and selects the replica set member with the lowest ReplicaID value.
While this algorithm and its underlying assumption might not be the most appropriate in all applications, it allows Microsoft Jet to quickly and consistently complete the synchronization process and preserves all the information from both versions for later review. The data from the record version that Microsoft Jet did not select is stored in a conflict table in the member where the change was made. Conflict tables derive both their names and fields from the underlying tables. Conflict table names are in the form table_Conflict, where table is the original table name. For example, if the original table’s name is Customers, the conflict table’s name is Customers_Conflict. Because conflicts are reported only to the replica set member that originated the losing update, conflict tables are not replicated.