Handling conflicts

Depending on the amount of data that is added and edited each day and the types of procedure that you have in place, the interval at which you should check for conflicts in the Conflict Viewer varies. To begin with, a suitable interval might be hourly, then after you know how frequently conflicts occur you can adjust the interval, for example, to once a day.

It is important to review the conflicts regularly as SQL Server will automatically delete the conflicts after a set time, for example after 14 days. You might want to discuss the length of this period with your SQL Server administrator.

Note: You must review all current conflicts before replication is disabled. The losing records in the conflicts are deleted when the SQL Server administrator disables replication. To make sure that you see all the conflicts, all fixed and disconnected Subscribers must be connected to the Publisher.

Minimizing the risk that conflicts occur

It is important to understand that the risk that conflicts occur is low where only fixed Subscribers are used— the risk increases with disconnected Subscribers because users at these Subscribers are working with data that is only periodically synchronized with the publication database.

Your existing working practices and procedures (that control how data is entered and updated) might already go a long way to minimize the risk that data conflicts occur. Especially if your procedures require analysts to consider the ownership of records before any updates are made.
  • Ask your SQL Server administrator to configure a message (an alert) to send an email, or a message to a pager, if replication is temporarily stopped.
  • Ensure that each record has an owner and that the owner's contact details are available. For example, you can enforce the ownership of records by adding an owner hyperlink field, as a standard field, to every entity and link type (see Adding owner fields to entity and link types for details). Contact details can also be added to the database in iBase by individual users using the Change User Information command on the File menu.
  • Review who has permission to perform batch edits and batch deletes as this type of operation is more likely to generate conflicts. In particular, batch deleting large numbers of entities.

Using the Conflict Viewer

You use the Conflict Viewer to review the conflicts that are automatically resolved in SQL Server. SQL Server resolves each conflict in favor of the Publisher and then in favor of the site that merges first. When you review a conflict, you either confirm that the conflict is resolved correctly or you change the outcome of the conflict, for example in favor of the other site or by editing the winning record.

When you finish, the losing record is purged from the database - this cannot be undone. If you change the outcome of the conflict, then the new outcome is replicated to all sites.

The record that is in conflict can be a modification or a deletion (held as a soft deleted record). When the outcome of a resolved conflict is a deletion, the record remains soft deleted.

To use the Conflict Viewer, you need to log on as a database administrator with full rights to the entity and link records. For more information. see iBase system roles. Your SQL Server administrator might also need to grant you specific rights.

To display the Conflict Viewer, in iBase select Replication Conflict Viewer from the Tools menu.

Working with disconnected Subscribers

You must review the conflicts that might occur when a disconnected Subscriber synchronizes with the Publisher.

Note: You might want to discourage operations such as importing, including imports scheduled by iBase Scheduler.

Handling a network communications failure

If network communications fail, changes cannot be merged with the Publisher. However, the database server can still be running so your users are able to continue working in the iBase database but with an increase in the risk that conflicts occur.

You can choose to:
  • Ask users to log on using a different server and open a different subscription database. This requires Windows Terminal Services or similar.
  • Allow your users to continue working and review any conflicts that might occur. However, you might want to discourage operations such as importing, including imports scheduled by iBase Scheduler.
  • Take the database offline to prevent anyone else from logging on. This allows users who are currently working to save their work before they close their session.