How do I deal with this problem? We have 13 people who will be receiving a link to a document, all of these people will have their department listed and a place next to there department for their input, therefore they are all editors. If I turn on the automatic edit mode then only one person gets to view the document, the others will get the message that the document is currently locked by someone, and then the document closes. If I go with the other option, turn off automatic edit mode. Now we have 13 people open the document in read mode. One person double clicks on it (while the others are only viewing it for the time) the person who put it in edit mode makes a change and saves it and closes it. The other people have never closed it from when they first opened it therefore it is not reflecting the changes made by the first person to put it into editmode, now one of them double click on it and turn it into edit mode they make the changes to it for their department, they save it and it tells them that it was saved by another user and asks them if they want to create a conflict document. How do I avoid this? If you say change how it handles conflicts then you are wrong! Please help. The solution is not obvious nor is it simple.
Subject: 13 people who all want to view the document problem
Use response documents - if you don’t like that solution you could have an agent add all of the responses into a field on the main document as they are saved. Append the author’s name and date before or after each entry.
You could also have an embedded view on the doc showing all of the responses to that document.
Subject: 13 people who all want to view the document problem
One possible way:
Instead of letting them edit it straight, create a button that runs a backend agent that gets their name and the correct fields associated with them and modify the documents in the back end. Perhaps do this by creating a document to store their input,move these values over on a Scheduled basis, and then delete the comments document.
And put “Continue=False” into the QueryModeChange event so that is cannot be edited in the client.
OR
Just use response documents for their comments and display these with an embedded view (much simpler option)
Subject: RE: 13 people who all want to view the document problem
As a matter of fact, you can. Create session and workspace objects, create string values representing either the NoteID or the UniversalID, the filepath and the server, then kill the UI document and any reference to the document, leaving no handles. Get the document again using NotesSession.GetDatabase and NotesDatabase.GetDocumentByID (or.GetDocumentByUNID), then create a new NotesUIDocument object using the EditDocument method of the workspace.
Subject: RE: 13 people who all want to view the document problem
Actually, no it doesn’t. I’ve been using it in production for quite some time now (relative to my total exposure to the Notes environment), including using an R5 “lock record” database instead of the ND6 locks, and haven’t had a single conflict since (well, except for that unfortunate agent incident, but that’s what you get for scheduling a big update during office hours…).
As long as the document is checked for locks (of whatever sort) whenever it goes into edit mode (both QueryOpen and QueryModeChange), you should be able to intercept save conflicts at least. Replication conflicts, though, require one to be a bit more restrictive, like bailing on edit mode period for local replicas in a location where the master lock server is unavailable.