User Help > Working With Documents > Modifying a Document > Using Multiple-Row Editing > Summarizing Assumptions and Rules for Resynchronizing > Assumptions and Rules for Resynchronizing for Client-Side Insert Operations
Assumptions and Rules for Resynchronizing for Client-Side Insert Operations
Assumptions
There is no mechanism to resolve a node with an informational conflict icon because there is nothing to resolve. The message associated with this type of conflict is strictly informational.
Nodes with informational conflict icons can be moved, edited, and deleted.
Performing a second resynchronization on a document that has a node with an informational conflict icon clears this icon if it is the node’s only conflict.
Nodes displaying conflict navigation icons are not real conflicts. Consequently, clicking a node that has this icon does not display a conflict item header or the editable item preview.
Rules
If an inserted node winds up with a different parent or previous sibling or path to the document root due to changes made on the server, the inserted node has an informational conflict icon .
It is possible for a node with an informational conflict to also have an edit conflict . For example, when you insert a node, that node does not yet exist on the server. In this case, the edit conflict icon is shown in the row header. The information messages for both conflict types are shown in the item header.
Inserts work in the same way as moves in the sense that the last one is the winner. If the client inserts node A under B while the server inserts node C under B, the order of nodes on resynchronizing is B, A, C. Because A under B is the last one created with respect to its position to B, it wins that spot.
If the parent of an inserted node has been deleted on the server, the new node is not lost. It appears as a child at the next level up.
If the sibling of an inserted node has been deleted on the server, the new node looks for the next real sibling and is inserted beneath it.
Was this helpful?