Rep Conflict Experts: Why do I still get conflicts when the form is designed to prevent them?

Users have local copies of the db. (many are remote) Here’s what I’ve got:

  1. The form has querymodechange code to first verify that the datetime last saved value is equal to the value on the server document. If not, editing is denied and replication suggested. (you can’t edit a document older than that on the server)

If last saved datetimes match, then it checks the server to see if anyone else has the doc locked. If so, editing is denied. (you can’t edit a doc that someone else is currently editing) If not, it creates a lock document on the server and allows the doc to be edited.

  1. If the doc is saved, it is datetime stamped, the matching doc on the server is deleted (by unid) and doc.copytodatabase is used to put the newly updated local doc on the server. Doc lock document is deleted.

From what I understand about conflicts, I should never get any - but I still do.

What am I missing? How can they still occur?

Subject: Rep Conflict Experts: Why do I still get conflicts when the form is designed to prevent them?

Why don’t you simply use the new built-in document locking in ND6?

flag = notesDocument.Lock( [ name ] [, provisionalOK ] )

It handles multi-replica databases.

Anyway, it’s fairly easy to determine the cause of the rep conflicts by simply looking at the doc properties (see sequence info on fields)