Conflict Detection
Applies to: SharePoint Foundation 2010
In addition to performance considerations, conflict detection is one of the most important synchronization topics.
Fetch-Send-Refresh
It is best to have conflicts detected and resolved by the client. The client can detect whether or not changes actually conflict, it can raise an alert to notify the user to manually correct a conflict, and it can store a copy of the changes made by the local user in the user’s storage.
For this reason, it is best if a synchronization operation includes three parts – first, data that is potentially changed is fetched from the server, then the client determines whether there are any conflicts with changes already uploaded in the client copy, and finally, if there is no conflict, the new client data is uploaded.
SharePoint objects may have some business logic applied at the point of the update. For this reason, the UpdateListItems(String, XmlNode) method returns the updated values of all the fields and properties of the updated items.
owshiddenversion Field
Windows SharePoint Services 3.0 uses the owshiddenversion Field (in the Microsoft.SharePoint.SPBuiltInFieldId Class) to detect conflicts. If this field value is not supplied during the update process, the server will overwrite all changes. A client must always supply this field value during the update process, in order to prevent data loss. The field value is the number that the server returned most recently.
The owshiddenversion Field value allows the server to determine if you are updating an outdated copy of an item. For example, a client synchronizes an item and gets a value of '2' for this attribute. In the interim, someone changes the title of that item on the server, so the value changes to '3.' When the client sends a change with a value of '2' and the item has been modified since the client last requested it, the server returns a TP_E_VERSIONCONFLICT (0x81020015) error and a list of the current contents of the item.
vti_versionhistory Property
The owshiddenversion field is sufficient for simple conflict detection when all clients are synchronizing with a central server. However; peer-to-peer synchronization presents further challenges. You want to avoid raising unnecessary conflicts when a change has been synchronized by a peer client.
Conflicts may also happen in a scenario that is not peer-to-peer. If a client successfully uploads a change to the server but does not receive an acknowledgment (response from UpdateListItems(String, XmlNode), the client must determine, at the next synchronization, that its most recent changes were uploaded.
ETag DAV Header
Document and attachment fetches and updates are performed by using the HTTP/DAV protocol (also known as WebDAV or DAV). This protocol uses a distinct mechanism for conflict detection. When you use a get accessor to get a file, which can include a document in a list, an attachment, or a page outside a list, an ETag is returned. The ETag includes another binary large object (BLOB) that contains a GUID and a version number. When you use the put accessor to upload a document, a client must request that the ETag matches the one supplied.
Note
Version history is not supported for this protocol.
Attachments
Although you can update attachments by using the HTTP/DAV protocol, to add attachments you must use the AddAttachment method from the Lists web service. This method accepts a binary array and returns the URL of the attachment.
For more information, see AddAttachment(String, String, String, []).