How to disable saving of "REP/SAVE CONFLICT" document completely ?

Simply

$Conflict  - Replication update caused it.. this is indicator that it is a conflict doc

$ConflictAction  - enable merge of conflict documents an action

~Hemanth

$Conflict -- if present, document is a relication comflict.

$ConflictAction -- specifies what the replicator should do if it detects a replication conflict in the document.

Tere is no way to be certain that you do/do not have a conflict at save time.  However, NotesDocument.Save takes two parameters that tell Notes what to do if the save finds a conflict.  The following code may be what you want:

If Not doc.save(false,false) then
   MsgBox "Save failed.  This may be due to a replication conflict" _
   & ", but could also be a 'regular' probelm with saving (network down, server down, access rights)"
End If

Note -- $Conflict is always an empty text field null string).

$ConflictActin takes different valuesfor different merge strategies. these are not documented.  In R4/R5, merging options were pretty limited, I'm not sure if there was anything other than "merge/don't merge."  In R6, there are additional options.

Put it simple...traping rep/save conflict is not possible ! But let me see if I can find some source/resource :-)

qualetee, What are the additional options in R6 for merge/donot merge rep saves conflict ?
Does $conflict and $conflictaction both exists in case of rep conflict and save conflict?

Hamantha, thanks for looking for me. please respond as soon as you find something.

I still don't know how to know which ones are rep conflicts and which ones are save conflicts ?

In my case, i don't have any reasons to believe that i m getting replication conflicts becasue i have only 2 servers where the db replicas are residing. One of them is read only. So i think all of them is save conflicts.. but just want some means to proof that ?

thanks again.

There is no realy way to tell the difference between a rep conflict and a save conflict.  To Notes/Domino, they are the same thing.

I forget offhand the newer options.  I think they specify how to choose a "winner," and whether to simply drop the losing conflict.

$Conflict by definition exists on conflict documents, and by definition does not exist on non-conflict documents.  As mentioned, conflict can mean repplication, or save conflict.  Note that a non-conflict document can have been previously a conflict document.  By removing the $Conflict, you turn it into a non-conflict. Note also that conflict documents are always created as responses ($Ref).

$ConflictAction can be present on conflicts, and can be present on non-conflicts.  It can also be absent from either.  If not present, it means that at any tiem in the future, if the doc develops a conflict, Domino wll use "traditional" conflict handling (no attempt to merge, winner is less edited document, or more stale if both are equally edited).

The form options for merge coflict cause any documents created with that form to have the $ConflictAction field set on them.

Note that a replication conflict can become further conflicted.  Imagone doc A has a conflict on Monday.  It ends up becoming A and B, a new conflict-response to A.  On Tusday, two scripts edit B simultaneously.  B will now get a conflict C.  C will be a response to B, and B a response to A.

What does $conflictaction = 1 means ? please explain other values. I have been seeing $conflictaction field as set to "1" in all kinds of documents whether they belong to a form that has properties checked with "merge replication conflict" or not.

How can a rep save conflict doc still created when the "merge rep.save conflict" is checked at the form level ? i understood that is used to prevent rep/save conflict.

Under what situation does a parent also becomes a child and there are 2 rep saves conflicts instead of 1 parent and 1 child?

$ConflictAction=1 means "replicator, please try to merge coflicts for this document."  Usually, it is set by the form property.  If the form does not have the property set, it could mean...

1) Form used to have it set, and this doc was created when form had it

2) Doc was originally created (or edited at some opint) using a different form

3) The $ConflictAction vaule was set by code, instead of the form property.

Merge conflicts means TRY to merge conflicts.  It checks which fields have been updated since the documents diverged.  If the changes were toa ll different fields, it will pull the updated fields from each doc and merge the results into a single non-conflicting document.

But,if there is even a single field that ws updated in both versions, the merge fails, and regular conflict handling takes place.  It is pretty dumb about that...

1) It does not check to see if "conflicting" fields have idnetical values, which would make the difference irrelevant, allowing the "identical" change to be ignored in one doc

2) It does not allow the option of partial merge (i.e., create a conflict, but for fields that arenot in conflict, propagate each change to both resulting documents)

3) It does not give the option of treating a particular field as an appendable list.  This means that any document with a built-in edit history by definition can't be conflict-merged.

$ConflicAction has only one value as "1" and if it is not present then form is not enabled to merge conflicts

Is it possible to have something like aborting the save / create of a new rep/save conflict document ?
Something like API that can give handle to the new conflict document before saving/creating it in querysave or queryclose. Or.. delete it as soon as it is created with a warning.

Fact: Creation of conflict cannot be avoided, it is totally managed by notes

What you can do is once the conflict is created, in the queryclose of the document check if this has $Conflict in the backend.. If so prompt the user that this has been marked conflict due to some save conflicts.. and it will be deleted. That is the approach...

I think in my case the save conflict may be only happening because of users getting slow db / network response during approval and their may be some field refresh or partial saves or multiple saves concurrently (during workflow, where the same fields might be getting updated multiple times) . OR Users may be getting impatient and trying to save it again when it is already in the process of saving from the first request. Is my thought process right ? Do you think what i m thinking may be true ? Correct me if i am wrong or elaborate more if you have experienced this before.

If the above is what is happening, how to prevent a conflict in such a case ? Are you sure there is no way to get a handle on conflicts even though it is managed by notes ?
I have 'Automatically refresh field' property checked off in all the forms.

HemanthaKumar,
> Fact: Creation of conflict cannot be avoided, it is totally managed by notes

Wrong.

On replication, it is impossible o avoid conflicts.

On client saves, where the conflict occurs because some other client edited the same repica copy of the same document in the same period -- of course you can avoid it.  Just do your own .save (false,false) in the QuerySave, and if you save fails, continue=false.

Hemanthakumar:
I tried several things according to your this suggestion but none worked. Please please help me here with doc.save(false, false) you talked about in querysave. I wrote something like this
in querysave event of the form.

If doc.Lock(0) = "Locked" then
 Msgbox ( "Error, document is locked by another user, cannot be saved" )
else
  continue = Savedoc(source)
end if


Function Savedoc (source as notesuidocument) as integer
..
set doc = source.document
..
..
if doc.Save(False, False) then
 Savedoc = True
Else
 Savedoc = False
End if
end function

As a result of this, i am always able to create a save conflict and it is not prevented.

Help me here.. please..Is there any other way using C API to check the save event and if that is creating a save conflict, just abandon everything or just don't allow it to save.

I think there is also a $ConflictAction that dumps the save.  Might only be R6.

If it were R6, the document locking feature would be more than enough to avoid conflicts...

Navgup, are you ready to move to R6 ???

yes we are ready to move to R6 but the issue is documnet locking won;t work in my case because i have related doc that needs to be locked as well.. it is like parent - child relationship where if someone is editing one child the parent and all sibling docs will have to get locked.

My code is designed to work that way..
but
1. if two users from 2 locations access different child of same parent and one gets control to lock all related docs, the user will get some control on few docs and they get save conflict.
2. If the doc is opened in two separate window by the same user, more like if the doc is saved from one window while the other one is open. it cause save conflict.

any suggestion..?