makuletski
asked on
Replication Save Conflict - kindda urgent
Can you guys help me determine what caused the replication save conflict of the two documents below by using the dates in the document properties?
Main Doc
Created: 04/18/2005 9:01:43 AM
Modified: 04/18/2005 10:50:38 AM
Added: 04/20/2005 10:32:15 AM
Modified (in this file) : 04/20/2005 10:36:22 AM
Modified by: User1's ID
Accessed: 04/20/2005
$Revisions: 04/18/2005 9:01:44 AM GDT
04/18/2005 9:17:32 AM GDT
$Updated By: Agent's ID
User1's ID
EEditor: User1's ID
EDate: 04/18/2005 10:46:57 AM GDT
Conflict Doc
Created: 04/18/2005 7:00:36 PM
Modified: 04/18/2005 06:58:34 PM
Added: 04/20/2005 10:31:19 AM
Modified (in this file) : 04/20/2005 10:31:38 AM
Modified by: Agent's ID
Accessed: 04/20/2005
$Revisions: 04/18/2005 9:01:44 AM GDT
$Updated By: Agent's ID
EEditor: User2's ID
EDate: 04/18/2005 11:19:46 AM GDT
* EEditor and EDate are fields from the document which records the last revision of the document
Any idea or intelligient guess will be appreciated!
Thanks in advance
Main Doc
Created: 04/18/2005 9:01:43 AM
Modified: 04/18/2005 10:50:38 AM
Added: 04/20/2005 10:32:15 AM
Modified (in this file) : 04/20/2005 10:36:22 AM
Modified by: User1's ID
Accessed: 04/20/2005
$Revisions: 04/18/2005 9:01:44 AM GDT
04/18/2005 9:17:32 AM GDT
$Updated By: Agent's ID
User1's ID
EEditor: User1's ID
EDate: 04/18/2005 10:46:57 AM GDT
Conflict Doc
Created: 04/18/2005 7:00:36 PM
Modified: 04/18/2005 06:58:34 PM
Added: 04/20/2005 10:31:19 AM
Modified (in this file) : 04/20/2005 10:31:38 AM
Modified by: Agent's ID
Accessed: 04/20/2005
$Revisions: 04/18/2005 9:01:44 AM GDT
$Updated By: Agent's ID
EEditor: User2's ID
EDate: 04/18/2005 11:19:46 AM GDT
* EEditor and EDate are fields from the document which records the last revision of the document
Any idea or intelligient guess will be appreciated!
Thanks in advance
Looks like user2 has opened doc before user1 and saved it after user1 saved it.. and hence raising conflict condition as both edits affect same field.
The soln to this kind of problem is lock the other user out when the doc is opened by someother user.. Plus add any timeout so that you can avoid users keeping the doc open for long time.
If you are using R6 document locking is implemented native to notes, with R5 you have to do it by yourself by recording the activities on a doc...
~Hemanth
The soln to this kind of problem is lock the other user out when the doc is opened by someother user.. Plus add any timeout so that you can avoid users keeping the doc open for long time.
If you are using R6 document locking is implemented native to notes, with R5 you have to do it by yourself by recording the activities on a doc...
~Hemanth
Go to document properties. Look at the last tab (advanced -- beanie icon). The middle line will end in something like -SN0000000A.
That is the document's "serial number," which really just means, how many times the document has been modified, using hex notation. In this case, F is hex for 15 (use Windows Calculator in Scientific view to convert).
Now, look at each field (second tab). The fields have a "sequence number" value associated with each, tis time in decimal form. The ones with a sequence number that matches the document sequence number are the ones most recently modified.
So, look for those in teh main/conflict docs.
Sometimes, the conflict could have occured earlier, if the docs were on two separate servers, and they were edited more than once. But most often, you can find it this way quickly.
That is the document's "serial number," which really just means, how many times the document has been modified, using hex notation. In this case, F is hex for 15 (use Windows Calculator in Scientific view to convert).
Now, look at each field (second tab). The fields have a "sequence number" value associated with each, tis time in decimal form. The ones with a sequence number that matches the document sequence number are the ones most recently modified.
So, look for those in teh main/conflict docs.
Sometimes, the conflict could have occured earlier, if the docs were on two separate servers, and they were edited more than once. But most often, you can find it this way quickly.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Sjef, neither of those do the sequence numbering checks. Those are what the replicator actually uses fro field-level replication.
Is this one going to stay open forever, too?
True once again, however, the first will give you a very easy overview of what's been changed. If you have a document with some 200 fields, this is way faster. I use the first myself, albeit a slightly modified version.
ASKER
No qwalette, this will not be open forever, i am however, still trying to apply some ideas you guys mentioned. I will be posting another comment once im done. i will also be closing the other question related to this one
ASKER
sjef,
the link you provided made my checking a lot easier
tnx a lot!
the link you provided made my checking a lot easier
tnx a lot!
Some info needed:
- how many servers have a replica of this database?
- what's the replication schedule or strategy?
- are there local replicas involved?
- what versions of clients and servers?
Most likely a user updated a document on one server and an agent did the same but on a different server. Notes doesn't know what document is the valid one, so creates a replication conflict document. You could try to set the form's properties to Merge replication conflicts, which means that if different fields are modified, then the conflic and the document will be merged during replication.