as I stumbled accross this issue a couple of weeks ago and found a workaround today. Some good'ole Notes Client stuff... .
What did I do ?
I created a Notes Document in LotusScript via an action button in a view. In the document, I changed some fields and used an action button to save the changes, close the uidocument, append some richtext via LotusScript to a richtext field an re-open the document using ws.editDocument(True,doc,,,False) in Edit mode again. We use this often if we have to append richtext programatically.
So far, so good. I continued editing in the UI and saved at some point - Notes wanted to create a save conflict due to multiple edits. The code I used for the above has not changed in years. The database has been using document locking for three years.
After some serious testing at the customer site, we learned that this behaviour started with Notes 9.0.1 FP8. Everyting earlier is fine, the problem also exists in FP9 and the 1st Beta of FP10, so something has changed since FP8 and after some more digging we came across document locking. It seems as if the sequence when the document gets unlocked by ui.close() and reopened (and re-locked) by ws.editDocument() must have changed - from FP8 onwards, the lockholders of the document re-openend for editing are empty for the UI Document but not for the backend document in the database ! So, indeed, there was an edit event happening in the backend after the re-open of the document in the UI.
After fiddeling around with some events, I found a workaround by writing the current user as lockholder into the document in the querysave event of the underlying form:
Sub Querysave(Source As Notesuidocument, Continue As Variant)
Dim doc As NotesDocument
Dim s As New NotesSession
Set doc = source.Document
If doc.LockHolders(0)="" Then
So with that, if I am the current lockholder in the backend, I can successfully save my changes without generating a save conflict.
Hope this helps if someone runs into a similar issue.