Conflicts and how they occur

A data conflict occurs when a user changes a record that has been changed by a user at a different site, within the same replication cycle.

Examples of data conflicts are:

  • Data in any field in the same entity is modified by two users, even if in different fields.

  • One user modifies a link, for example gives it a direction, but a different user deletes it.

  • One user adds a link but a different user deletes a link end entity for that link.

In normal circumstances, it is unlikely that any data conflicts occur in systems with fixed Subscribers only because changes from Subscribers are merged continuously with the Publisher and replicated to the Subscribers almost immediately.

For a conflict to arise, the first update to a record and the second conflicting update must merge with the Publisher before the Publisher can replicate the first update to the Subscribers. In this example, Sites A and B make conflicting changes to the same record:



In this example, a conflict occurs because Site B merges its change into the publication database before the Publisher can replicate the change made by Site A. The conflict is automatically resolved in favor of the first change to merge at the Publisher (Site A), and it is this record which is replicated to Site B. The outcome would be the same if Site A was actually the Publisher.

Conflicts are most likely to occur when disconnected Subscribers connect to the Publisher or when a failed communications link comes back online.

All conflicts are resolved automatically by SQL Server which replicates the modification or deletion to all sites. You need to review all the conflicts in the iBase Conflict Viewer. If required, you can change how the conflicts were resolved. Changing the outcome of a conflict updates the publication database and replicate the change to all the subscription databases.

Note: Conflicts must be reviewed before you can purge or restore soft deleted records, and before the SQL Server administrator disables replication. All conflict data is lost when replication is disabled by the SQL Server administrator.

Understanding the Conflict Viewer

Conflicts are reviewed using the iBase Conflict Viewer, in the publication database only.

The user who reviews the conflicts must decide whether to keep the "winning" record in the conflict (the record currently seen at all sites) or replace it with the "loser". When they confirm their decision, the record they choose to discard is purged from the database. Before they confirm their decision, they can edit the record they want to keep, for example, to include details from the record that is purged.

If the outcome of the conflict is changed, the records are replicated to all the subscriber sites to update the databases and produce a consistent view of the data across all the sites. If the decision is to keep the original outcome, then nothing is replicated and the databases remain unchanged because they already have the data.

The following figure summarizes the iBase Conflict Viewer. The Subscriber to merge first with the Publisher is presented as the winner, and the Subscriber to merge second is presented as the loser:



Note: The records that are displayed might contain several conflicting changes, for example to both the link direction and to a field in the link.

Note: It is important to remember the deletions and modifications that are shown in the Conflict Viewer have already taken place. The winning record is already seen at all fixed Subscribers, and at any disconnected Subscribers that are online and connected to the Publisher since the conflict was resolved. You use the Conflict Viewer to either confirm that the deletion or modification was correct, or to change the outcome.  

The different types of conflict are described in detail in the following information:

Unless otherwise stated, the examples given in the following sections apply both to a conflict automatically resolved in SQL Server or to a conflict reviewed in the iBase Conflict Viewer.

Conflicting changes to an entity

In this example, the Subscriber at Site A deletes the entity but the Subscriber at Site B changes it in some way:

  • If Site A wins the conflict, the entity is soft deleted at all Subscribers.

  • If Site B wins the conflict, the entity is updated at all Subscribers, and users at Site A see a restored entity, in its updated form.

Conflicting changes to a link

In this example, the Site A Subscriber deletes the link while the Site B Subscriber adds a direction to the link:

  • If Site A wins, the link is soft deleted at all Subscribers.

  • If Site B wins, the link is updated at all Subscribers, and users at Site A see a restored link with the update made by Site B.

Note: There is a similar outcome if the change at the Site B Subscriber is a change to a link field.

Non-conflicting changes to a link

Conflicts on links occur only:

  • Between fields in the link record

  • Between the link direction, strength, or both

  • Between the link end entities

A conflict cannot occur when, for example:

  • One site changes a link field and another site changes a link end entity

  • One site changes the link direction or strength and another site changes a field in the link record

Even though these changes are not conflicts, they are detected by the Conflict Viewer, which highlight just the Modified Date and Modified By fields as the difference. However, if one site changes any of the fields in the link, then the conflict presents itself as a conflict between the link fields.

See Unsupported Conflicts for changes that involve both link end entities.

Conflicting changes to an entity with links

In this example, the Site A Subscriber deletes the entity, which automatically deletes the two links, and the Site B Subscriber changes fields in the entity but leaves the links untouched:

Initial record

Site A change

Site B change




How this type of conflict is handled by SQL Server and the Conflict Viewer is different from a conflict that involves just links or just entities.

If Site A wins, the conflict is resolved as you would expect by SQL Server, which replicates the deleted entity and links to the other databases. When you review the conflict in iBase (and click Apply below the Winner area to confirm that the change made at Site A is correct), nothing is replicated to the other databases because they already have the correct data. This is the usual behavior.

However, if Site B wins, the conflict is not resolved as you would expect in SQL Server because it cannot restore the soft deleted links which is a feature of iBase. Therefore, SQL Server replicates the updated entity as changed at Site B and the soft deleted links as deleted at Site A. As a result all sites see the data in this state until you review the conflict in the Conflict Viewer:



To correct this, use the Conflict Viewer. In this example, it reports that two links are affected by this update. When you click Apply below the Winner area to confirm that the change made at Site B is correct, the links are restored and replicated to the other databases.

Broken links

In this example, which is not a conflict, the Site A Subscriber deletes the link end entity (and therefore the connecting link) while the Site B Subscriber adds a link:

Initial record

Site A change

Site B change




If Site B wins, the new link is replicated to all Subscribers, and users at Site A see a restored entity with the new link added by Site B.

If Site A wins, the link end entity and its link are deleted at all Subscribers, however, at Site B, there is a broken link because the new link is left without one of its link end entities:



For this reason, after the conflict is resolved, you use an extra facility in the iBase Conflict Viewer to ensure the integrity of all records. You can either delete the broken link or restore the missing link end entity. Therefore, the final outcome will be one of the following:

Deleted link

Restored link end



Note: This type of conflict is specific to iBase, and is not visible in the SQL Server Conflict Resolver.

Conflicts between three or more sites

It is possible for three or more sites to make conflicting changes to the same data. The conflicts are listed in the Conflict Viewer in the usual way (by the record label of the winning record). The second conflict that is listed in this example occurs between a third site and the "winner" of the first conflict:



Conflicts when records are deleted

Conflicts occur when users at different sites delete the same entity, link, or entity with links. Although the outcome of these conflicts is the same regardless of which site wins the conflict, you might want to investigate why users at different sites are deleting the same records.

Unsupported conflicts

Merge conflicts and a specific type of link end conflict are not supported in the Conflict Viewer.

Conflicts resulting from merging

Conflicts arising from merging entities are not supported, and cannot be viewed in the Conflict Viewer. You need to set up a procedure to prevent these conflicts from arising. See Merging Entities for working practices.

Conflicts resulting from changing different or both link ends

A link where different, the same, or both link end entities are changed is detected by the Conflict Viewer as a change to the link, and not as a conflict. In the Conflict Viewer, there is no visible difference between the two records apart from the Modified Date and Modified By fields.

For example:

Changes made

Site A - Site B

This is the original link before the link end entities are changed:


Site A changes one of the link end entities and is the first to merge with the Publisher.


Site B changes the other link end entity and merges last. This overwrites the Site A change. You cannot change this outcome in the Conflict Viewer.