Conflict definition/conflict resolution issue,
As I understand, the conflict resolution states which database is determinant in case of conflict. What I couldn�??t figure out is the impact of conflict definition (by object/by attribute).
What I couldn�??t understand is the impact of setting the conflict definition to be by object or by attribute. In these two cases, the result is the same. Both spatial location and attribute values are updated
What is significant about the conflict definition (by object/by attribute)? where its impact can be felt?
Just to make sure you don't misunderstand this: in the end, it is always you as a user who needs to determine which state of an object is the right one, and needs to be maintained. Even if you set an (automated) option, like "in favour of target", you are making an important decision, namely to always favour the target! You really need to consider if you want automated reconcilation or not, and this determines your workflow setup. You may need to have manual intervention by someone with authority to determine which state is right.
Another thing you really need to understand fully is, that by definition, any reconcilation will always lead to fully identical features on both the parent and child. This means that BOTH the geometry AND all its attributes will be exactly the same. The reason for this is that, after reconcilation and post, the two features will point to the same database state. This means that it is absolute impossible to have two features not being fully identical, because both features from the parent and child version are pointing to exactly the same database record!
If you set "BY_ATTRIBUTE", you are just telling ArcGIS to automatically and silently merge attributes updates to two or more different fields, and to not flag them as a conflict.
E.g., if you initially have feature A in the parent with a value of "Oak" for the field "Tree_species" and "30 years" for field "Tree_age", and the tree species in the parent is updated to read "Birch", while the tree age is updated in the child to be "40 years", than the resultant feature will have "Birch" and "40 years" after reconciliation in both parent and child. See below.
"Tree_age":"40 years" (EDIT!)
AFTER RECONCILIATION (no conflict detected with option "BY_ATTRIBUTE"~~!)
As you can see, both edits are silently merged without a conflict being raised, because the attribute changes in parent and child are on different fields and can be merged without causing an inconsistency.
Based on valuable elaboration you have already provided, is it correct to say:
1. If the conflict definition is set to be �??by object�?� then only spatial changes applied to the same FEATURE (in the parent and child) will be considered as conflict and will be flagged for further work. In this case, attribute changes applied to the same record FEATURE (in the parent and child) will never be considered as conflict.
2. If the conflict definition is set to be �??by attribute�?� then only tabular data changes applied to the same RECORD (in the parent and child) is considered as conflict and will be flagged for further work. In this case, spatial changes applied to the same FEATURE (in the parent and child) will never be considered as conflict.
NO (for both questions).
You are misinterpreting what I am saying.
The confusing part is the use of the word "object" in the BY_OBJECT argument. Object is not meant to reference the spatial feature stored in the geometry column, it is meant to refer to the entire record, that is, BOTH the geometry and attribute fields.
With BY_OBJECT, all changes to any geometry or attribute field of the same database record (NOTE 1, see below) will be flagged as a conflict. It essentially means that two editors can not edit the same record, without ArcGIS flagging it as a conflict upon reconciliation.
When you use BY_ATTRIBUTE, two editors CAN edit the same record without causing a conflict, however, only as long as they edit different fields.
See the example in my previous post where the editor of the parent version changed the field "Tree_Species" to "Birch", while another editor changed the field "Tree_Age" to "40" in the child version. These edits were merged silently upon reconciliation, without raising a conflict. In essence, BY_ATTRIBUTE relaxes editing constraints, allowing you to have multiple editors making edits to different fields, without the extra burden of generated conflicts. If the editor of the parent had changed the field "Tree_Age" as well, and had set it to for example "50", than reconciliation with BY_ATTRIBUTE would have generated a conflict as well, just as with BY_OBJECT.
Although this may sound attractive, you should use it with caution, because it will also mean edits done by multiple users to the same records will be automatically and silently merged. If your workflow instead requires consistent "single user" - bad wording here, since you're still in the versioned editing workflow - editing against entire objects / records, than you need BY_OBJECT.
Be aware though, that BY_OBJECT doesn't prevent multiple users from editing the same records (remember we're talking about versioning, so by definition multi-user editing), but it will flag two edits on the same object / records as a conflict. So you still have all reconcilation options allowing you to chose which representation (parent or child), is the right one.
Also see this Help page:
Reconcile Versions (Data Management)
and especially the topic "conflict_definition" there
*** NOTE 1 ***
I would probably better say "object" here, instead of "database record", as the edits to the child version are of course stored in the A/D delta tables, so in reality are in different database records compared to parent before reconciliation. It is the identical OBJECTID that determines which records in the A/D delta tables representing the child version edits, are related to the parent version.
2. �??by object�?� (feature/record) considers edits (from multiple versions) occurring on the same feature (spatial change such as: move/reshape/delete) AND/OR on the same record (not necessarily the same CELL of a particular field) to be a conflict
3. �??by attribute�?� (cell) considers ONLY edits (from multiple versions) occurring on the same Cell (of particular field/record) to be a conflict and thus �??by attribute�?� is just a special case of the �??by object�?� and limits
Am I correct now?
1. The issue of conflict definition merely refers to what the system considers as conflict or doesn�??t and has no impact on the reconcile/post
... As I understand, the conflict resolution states which database is determinant in case of conflict. What I couldn�??t figure out is the impact of conflict definition (by object/by attribute). ...