Merging entities

The Conflict Viewer, handles conflicting changes to entities and their links that arise from direct editing or deleting of the records; it does not handle conflicts that arise from merging entities or occurring in the records affected by a merge operation. A typical example of this type of conflict is someone edits a link that is deleted as a result of a merge performed at a different site.

About this task

For this reason:

  • Only authorized users can access the Merge Entities options.

  • You need to establish a procedure for reviewing and merging entities so that only one user at a time merges entities, preferably using the publication database.

  • You need to review any existing procedures that might add to the number of duplicates in the system.

It is important to restrict who has access to Merge Entities This ensures that only users who understand the impact of merging entities on a replicated database have authority to perform this operation.

Note: Merging is part of the same command group as batch editing and batch deleting.

The objective of this procedure is to ensure that only one user at a time merges entities to prevent merge conflicts from arising in the first place.

Each site needs to appoint a senior analyst with responsibility for carefully analyzing the records involved in a merge. Depending on the procedure, they might have permission to also perform the actual merge, or you might choose to restrict this to a single user account.

A senior analyst at each site must carefully analyze the records involved in the proposed merge. There are various ways of organizing this. For example, if you want to use iBase to manage this, a possibility is to define a Merge Request entity type in your database schema, which would contain the information that relates to the merge, and use this as a way of reviewing and getting agreement on the decision to merge.

The procedure would be, for example:

Procedure

  1. When records are identified as candidates for a merge, a senior analyst charts the records involved to an Analyst's Notebook chart and saves the chart as a record of the pre-merge data.

    Note: This is also a useful way of restoring the data to its original state if a problem is discovered with the merge later.

  2. Using iBase, the analyst adds a Merge Request entity that contains details of the records involved in the proposed merge. Depending on how you choose to design the Merge Request entity type, the analyst also includes a screen capture of the pre-merge data to help the review.

  3. When the Merge Request is saved, it is automatically replicated to all databases for review. Analysts responsible for reviewing merge requests have set up a browse definition that auto runs when they log on, and that tells them when a new merge request is waiting to be reviewed.

  4. Each analyst reviews the details of the proposed merge, and updates the Merge Request entity. There should be space for each analyst to add comments. After saving, their review comment is replicated to the other databases so that other reviewers can follow the progress of the review.

    Note: There is a risk that conflicts occur if two or more analysts edit the Merge Request record within the same replication cycle. In this situation, review the record in the Conflict Viewer in the usual way, taking care to copy the comments from the losing record to the winning record before you click Apply.

  5. After all the analysts review the merge request, the nominated user merges the records. To do the merge, they:

    • Should work in the publication database

    • Check that all Subscribers are online (a conflict can occur when a communication link, which was down, comes back online)

    They can either:

    • Select one record to keep as the merge entity, and merge the other entity records into it

    • Create a new entity of a suitable type and merge the existing records into this.

  6. After the merge is complete, you might want to update the owner of the merged record (if you use owner hyperlink fields).

What to do next

Designing a Merge Request entity type

For information on what to consider to design a suitable entity type for Merge Requests, see Updating the Database Design.

Note: Adding a Merge Request entity type is a change to the database schema and must be done before the publication database is configured for replication in SQL Server or when replication is disabled in SQL Server.

How are duplicate records created at the moment?

Consider whether there is any scope within your current working practices to reduce the number of duplicate records that are added to the system. For example:

  • Are users importing data that contains duplicates and then using merge to remove the duplicates? In this case, consider how you might clean your data before you import it into a replicated database.

  • Check that you have discriminators set on all your entity and link types to prevent users from accidentally entering duplicates.

  • Avoid performing batch edits, especially on discriminator fields.

What to do if a conflict occurs

A typical conflict that arises from a merge is, for example, someone edits a link or entity before someone else performing a merge in which the entity or link is deleted. The iBase Conflict Viewer cannot display the context in which this conflict arose, and it is not possible to use the Conflict Viewer to restore it to its original state.

In this situation, the best course of action is to use the chart that contains the pre-merge data to recreate any missing data. It is also possible that your SQL Server administrator might be able to use an SQL Server Conflict Resolver to restore some of the data.

To avoid this situation from arising in the future:

  • Always chart the data to Analyst's Notebook and then save a chart before a merge--- this gives you the opportunity to recreate the data if you discover a problem.

  • Do not merge if any Subscribers are offline.