For a while now I’ve been niggled by a quirk that I couldn’t understand the cause of. In one application, which uses a lot of local replicas and has been in use for many years, I occasionally had calls about documents that had “disappeared”. In each occasion I tracked them down as conflicts. But the strange symptom was that the $REF field – which gives the parent UNID – was the same as the document’s UNID. In effect, it was a response to itself. Various searches online never elicited a potential cause and I couldn’t see anything specific that explained it. At some point in the distant past I had even tried setting the Form property to “Merge/No Conflicts”.

Until this week, that is.

This week I happened to look at the modified initially date and time of each document. Obviously the modified in this file date and time would be the time it was added to the server replica and I didn’t expect this to be of relevance. Maybe this was what I had been looking at previously. But as soon as I compared the modified initially date and time on each, something immediately jumped out and the seemingly obvious explanation for symptom and cause promptly followed.

The first is the conflict that is a child of itself, the second conflict is the child of the first. Other examples all reinforced the same hypothesis – the cause is when a document is edited in two different local replicas at exactly the same time. Obviously when they come to the server, there is no “most recent” document, so no way to identify the “winner”. As a result, both became conflicts.

Historically there have been various fields that recalculate on every save. From years of troubleshooting Domino applications I’ve seen the profoud benefit of having the Seq Num property of each item, which corresponds to the nth save of the document. That corresponds to the programmatic call to NotesItem.lastModified (which gives a date). As a result, at some point I intend to review the application and find a way to avoid the relevant items being updated on every save. That should prevent the problem at source, because there will no longer be conflicts at item level, allowing them to be merged.

4 thoughts on “Replication / Save Conflict of Itself”

  1. I very occasionally see the same thing. I can’t remember seeing this in early versions, have you? Surely if it was as a result of two separate edits at exactly the same time this issue would have occurred before? Of course I could have been just lucky, or not noticed them before.

    1. I’m not sure if it’s related to the “rule” applied for conflict handling on the form, or it could be a change of behaviour in a version. I think it’s tied very much to user behaviour. I’m guessing it’s when two people on different local replicas are on the phone, discussing and making changes to the same document at the same time. That could be tied to changes in how users work with the application.

  2. I know if another thing that can make really strange behavior regarding replications and note ID:s and that is the following
    If a UNID doesn’t exist in a database Domino will keep that UNID when copying or pasting the document. OK that is good you might say.
    But there is an BIG but, it will not take deletion stubs in consideration.
    So if a UNID is deleted in a database and replicated around the system and deleted somewhere and added in other places. This will give very strange problems.

    1. When pasting a document, it will not keep the same UNID if there’s another note (or deletion stub) with the same UNID. So if you paste a document, then delete it, then paste it again, the new copy will have a new UNID. However, there are ways to confuse the system; for instance if you paste in one replica, then delete, then paste in another replica that hasn’t gotten the news yet about the original paste let alone the deletion, you would end up with a duplicate UNID and the new document would probably be deleted during replication. Is that the sort of thing you mean?

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top