Share via


Resolving Conflicts

Conflicts can occur when a workspace member modifies a record without first receiving all previous changes to that record by other workspace members. In this case, SharePoint Workspace cannot determine the correct state of the record or attachment. It handles this by creating conflicts that each store the record or attachment as set by a different workspace member. It selects one record or attachment to be used in ordinary operations. But it allows the add-in tool to replace the selected record or attachment by using one of the other conflicts.

The add-in API handles conflicts to records and attachments independently. If workspace members create a conflict and it is only a conflict to an attachment, there will only be conflicts on the attachment. If workspace members create a conflict and there is both a conflict to the record and a conflict to the attachment, then SharePoint Workspace creates separate conflict records and conflict attachments. There is no automatic connection between the conflict record and the attachment conflict created from a single workspace endpoint. In many cases, your add-in code can determine the relationship by examining the identity URL of the member who made the updates. But it is possible for a single workspace member to open the add-in on separate endpoints. In this case, there is no automatic way to determine the conflict record and the conflict attachment which originated on the same endpoint. If your add-in business logic specifies that there is a relationship between the value of an attachment and the value of the columns in the record, then it must ensure that it resolves the conflicts in the record and the attachment so that the relationship is maintained.

Each data row has a "_HasConflicts" system property. This property is set to true if that row has a conflict. This lets you determine which records have conflicts. When you are accessing a DataRow that has a conflict, you can call the following .NET extension methods:

  • GetConflicts method is called on the DataRow selected to be used for ordinary operations. This method returns all conflict DataRows including the one selected for ordinary operations. A _VersionID field on each row uniquely identifies a conflict row.

  • ResolveConflicts method is called on the conflict DataRow selected by the add-in to be the winner. All other conflict rows are deleted and this DataRow is used for all operations.

Each Attachment object has a HasConflict field that specifies whether there are attachment conflicts. When you are accessing an attachment that has a conflict, you can call the following methods:

  • GetConflicts method is called on the attachment selected for ordinary operations. This method returns all conflict attachments. Each attachment conflict has a VersionID property to help your add-in differentiate between the conflicts.

  • ResolveConflict method is called on the conflict attachment selected by the add-in to be the winner. All other conflict attachments are deleted and this attachment is used for all operations.

Note

The DataRowResolveConflicts method and the attachment ResolveConflict method are executed immediately on the underlying data without waiting for an Update call.