Sequence of reconcile/post from multiple versions to default ArcSDE geodatabase,

[JamalNUMAN]

Sequence of reconcile/post from multiple versions to default ArcSDE geodatabase,

Multiple versions are created from the default ArcSDE geodatabase. I couldn???t figure out how the reconcile/post is performed?


[ATTACH=CONFIG]25154[/ATTACH]

How about the sequence of reconcile/post between the default ArcSDE geodatabase and these multiple versions? With which version the default ArcSDE geodatabase is first reconciled/posted?

For example, is the default ArcSDE geodatabase first reconciled/posted with Sami's version or Reda's version? which edits of these two versions are first transferred to the default ArcSDE geodatabase?


Thank you

Best

Jamal

[JamalNUMAN]

Not necessarily..., it may get a bit complicated now, but versions reference so called "database states". Each time you make any type of edit to a Feature Class, you create a new "database state", and the version starts referencing that state from that moment onwards until the next edit completes. The database state references a certain combination of records in the base table and A/D delta tables. Your single version may actually go through a whole set of "states" during its life-time until you delete the version once you no longer need it. Even during a single edit session (the time in between clicking Start Editing and Stop Editing in ArcMap), your version may go through multiple states, as you can perform multiple edits in a single edit session.

It is the time you complete your edits (transaction closing time?) to specific records / geometries, which ultimately determines which records / geometries might be considered the "valid" or last "state" of the object they represent. It is this time and database state information that is used in the (batch) reconciliation and post process to determine if there are any conflicts due to other users having edited, saved and posted the same object to the same target version before you post it. You can than use the reconciliation tools to review the conflicting states and determine whether you favor the current target, or your own edit version.

So don't confuse the creation time of the version with the save / completion times of specific edits to specific records / geometries.

Jamal, I also strongly encourage you to read Derek Law's basic introduction to versioning to better understand what is going on "under the hood":
Versioning 101

And for a really comprehensive overview (older 2004 document, but the mechanism of versioning described there is still highly relevant):
Versioning - ESRI Technical paper

Hi Marco,

I have tried to figure out the way the updates are done (in case of conflict) when received from multiple versions.

Scenario:

1. I got sde.default from which two users got their versions (u1.u1 and u2.u2)

2. The u1.u1 and u2.u2 are updated as show in the screenshot below:

[ATTACH=CONFIG]27915[/ATTACH], [ATTACH=CONFIG]27916[/ATTACH]

a. Feature #11 stays the same in the sde.default
b. Feature #11 is moved to left in version u1.u1 and saved
c. Feature #11 is moved to right in version u2.u2 and saved
d. Feature #9 stays the same in the sde.default
e. Feature #9 is moved to left in version u1.u1 and saved
f. Feature #9 is moved to left in version u1.u1 and saved




3. The result is as shown below

[ATTACH=CONFIG]27917[/ATTACH]


Very confusing! I expect that the updates of feature #11 will follow the u2.u.2 version (since the most recent edits occurred there) while the updates of feature #9 will follow the version u1.u1 (since the last edits occurred there)

What is confusing that the both conflicts are updated based on the u1.u1 version! How come the u1.u1 is the determinant?

I tried to do other conflict changes and found out that the updates of the u1.u1 are considered!

What might be the issue here?


Thank you

Best

Jamal

[MarcoBoeringa]

Jamal,

Before I (or someone else) can answer this properly, can you tell me one thing:

Is version U2 derived / based on / a child of version U1 or is version U2 derived from SDE.DEFAULT directly?

[Anonymous User]

Original User: Jamal432@gmail.com

Jamal,

Before I (or someone else) can answer this properly, can you tell me one thing:

Is version U2 derived / based on / a child of version U1 or is version U2 derived from SDE.DEFAULT directly?

Many thanks Marco.

U2 version is derived directly from the default version. The tree is shown on the screenshot below:

[ATTACH=CONFIG]27938[/ATTACH]

[MarcoBoeringa]

Many thanks Marco.

U2 version is derived directly from the default version. The tree is shown on the screenshot below:

[ATTACH=CONFIG]27938[/ATTACH]

Thanks for the answer, but I realized it is actually irrelevant here. What IS relevant, is the reconcile order shown in your screenshot (target <--- u1 <--- u2 <--- u3), and the fact that you chose FAVOR_TARGET_VERSION.

Very confusing! I expect that the updates of feature #11 will follow the u2.u.2 version (since the most recent edits occurred there) while the updates of feature #9 will follow the version u1.u1 (since the last edits occurred there)

What is confusing that the both conflicts are updated based on the u1.u1 version! How come the u1.u1 is the determinant?

I tried to do other conflict changes and found out that the updates of the u1.u1 are considered!

What might be the issue here?

"What might be the issue here?"

There is no issue here, ArcGIS is behaving exactly as expected, and as you yourself ordered it to do!

"How come the u1.u1 is the determinant?"

This is because you ordered ArcGIS to resolve conflicts in favour of the target version, by setting FAVOR_TARGET_VERSION in the geoprocessing dialog.

What you have to realize is that the list of edit versions shown that will be reconciled, is not an arbitrary list, it is ordered in the sequence the versions will be reconciled against each other. If you perform batch reconciliation, versions are always processed in pairs of two: one target and one edit version. So even though you have 3 edit versions here, only two of them are reconciled and post at a single point in time during the batch reconciliation.

ArcGIS determines the recommended reconciliation order based on the save times of the edits. In your case, the dialog shows that ArcGIS will perform three reconciliation and post cycles, in the following order starting at 1) and ending at 3).

1) u2 <--- u3
2) u1 <--- u2
3) target <--- u1

As you can see, u3 will be reconciled and post first against target u2, than u2 against u1, and finally u1 against the main target (SDE.DEFAULT in your case).

Since you chose BY_OBJECT and FAVOR_TARGET_VERSION, any conflicting edits in u3 and u2 will be dropped(!) (remember you learned this from my post in the other thread you started).

This is exactly what is happening:

You created a conflict by moving point 11 in both version u2 and u1:

a. Feature #11 stays the same in the sde.default
b. Feature #11 is moved to left in version u1.u1 and saved
c. Feature #11 is moved to right in version u2.u2 and saved

Since the target version in the reconcilation of step 2) u1 <--- u2 is version u1, and you chose to favour the target, the edit of u2 is dropped, and the u1 edit remains:  "b. Feature #11 is moved to left in version u1.u1"

Since this edit b. is not in conflict with SDE.DEFAULT, it is reconciled and post to target version SDE.DEFAULT in the next step: 3) target <--- u1

And as you see and hopefully understand now, the edit of u1 takes precedence over the edit of u2, as you ordered ArcGIS to do by setting FAVOR_TARGET_VERSION.

[Anonymous User]

Original User: mboeringa2010

One last and very important note about the whole reconcile & post of editing conflicts in the versioned editing environment:

You should bear in mind, that conflict detection & reconciliation, is only a last resort to fixing errors that shouldn't be happening in the first place. If you give good working orders to your employees / editors, the amount of conflicts should be minimal. Editing conflicts can arise when users edit the same area, or make accidental mistakes by entering values for the wrong record (e.g. one record above or below what they intended).

The versioned editing environment of ArcGIS, and its associated conflict detection & reconciliation was never meant to replace good workflow design and best practices for editing and work distribution / task designation among multiple editors.

[Anonymous User]

Original User: Jamal432@gmail.com

One last and very important note about the whole reconcile & post of editing conflicts in the versioned editing environment:

You should bear in mind, that conflict detection & reconciliation, is only a last resort to fixing errors that shouldn't be happening in the first place. If you give good working orders to your employees / editors, the amount of conflicts should be minimal. Editing conflicts can arise when users edit the same area, or make accidental mistakes by entering values for the wrong record (e.g. one record above or below what they intended).

The versioned editing environment of ArcGIS, and its associated conflict detection & reconciliation was never meant to replace good workflow design and best practices for editing and work distribution / task designation among multiple editors.

Many thanks Marco for the very useful elaboration.

Sounds that I didn�??t get the game yet!

In the attached screenshots, in which scenario the edits of u2, for example, will be taken? Again the edits of u2 are always taken.

During the reconcile/post, the system arranges the order as follows regardless the �??save time�?�!
1. reconcile from sde to u1 and then post from u1 to sde
2. reconcile from sde to u2 and then post from u2 to sde
3. reconcile from sde to u3 and then post from u3 to sde

[ATTACH=CONFIG]28078[/ATTACH]

How the order can be (so that the edits of u2 are taken):

1. reconcile from sde to u2 and then post from u2 to sde
2. reconcile from sde to u3 and then post from u3 to sde
3. reconcile from sde to u1 and then post from u1 to sde

[ATTACH=CONFIG]28079[/ATTACH]

[MarcoBoeringa]

Sorry Jamal for causing more confusion, but I made a serious error in post 13 when I attempted to describe what is happening. It doesn't influence the end result though (u1 edit being favoured over other edits), as the cause of your issue remains the same, favouring the target version in case of a conflict, instead of favouring the edit version. You need to change your settings in the "Reconcile Versions" toolbox dialog if you want other results. See below for the explanation.

ArcGIS determines the recommended reconciliation order based on the save times of the edits. In your case, the dialog shows that ArcGIS will perform three reconciliation and post cycles, in the following order starting at 1) and ending at 3).

1) u2 <--- u3
2) u1 <--- u2
3) target <--- u1

This part of what I wrote in post no. 13 isn't correct. It is only correct if u3 was deliberately reconciled against u2, u2 against u1 and u1 against SDE.DEFAULT (in your example).

You showed in the screenshot the reconcilation to follow the path:

1) target <--- u1
2) target <--- u2
3) target <--- u3

So in reality, all versions in a "batch reconcilation" action are reconciled and posted against the target directly (SDE.DEFAULT in your case).

Still, this doesn't change things as far as the results, as you chose "FAVOR_TARGET_VERSION". Since u1 is reconciled and posted first, the edit of point feature 11 in u1 will take precedence over edits to the same feature 11 in versions u2 and u3. The edits therein will be ignored and not posted to the target SDE.DEFAULT. This is what I see happening in your screenshots.

How the order can be (so that the edits of u2 are taken):

1. reconcile from sde to u2 and then post from u2 to sde
2. reconcile from sde to u3 and then post from u3 to sde
3. reconcile from sde to u1 and then post from u1 to sde

[ATTACH=CONFIG]28079[/ATTACH]

If, by this, you mean the edits of u2 should be favoured over u1 because they were saved the latest, you need to change the "conflict_resolution" parameter from "FAVOR_TARGET_VERSION" to "FAVOR_EDIT_VERSION".

Choosing FAVOR_EDIT_VERSION will mean that in case of a conflict (and feature 11 from u2 is in conflict with target "SDE.DEFAULT" when the edits of u1 are already posted in the first reconcilation and post step), the edit version will take precedence over the target version, meaning the edit of feature 11 in u2 will be posted to target SDE.DEFAULT, "overwriting" the previously posted edit of u1.

[MarcoBoeringa · Accepted solution]

Jamal, there are a few more things to take notice of:

Basically, in a comparison of any two versions, there are two types of feature edits to be distinguished:

- Those not in conflict
- Those in conflict

What happens with these feature edits?

Those not in conflict
If there is no conflict between edit version and target for a particular feature, any edit to a feature in the edit version will be automatically posted to the target.

Those in conflict
If there IS a conflict, the setting you choose for "conflict_resolution" (FAVOR_TARGET_VERSION or FAVOR_EDIT_VERSION), will determine whether the state of the conflicting feature in the target, or the state of the edit version will be maintained in the target after the reconciliation and post.

If you choose FAVOR_TARGET_VERSION, NO posting of the conflicting feature edit in the edit version will take place, and the target versions representation remains the same as it was.

If you choose FAVOR_EDIT_VERSION, posting of the conflicting feature edit in the edit version will take place, and the target versions representation will be replaced by the edit version.

So the "conflict_resolution" parameter of the "Reconcile Versions" tool only affects / concerns features that are in conflict. This setting does nothing for all the remaining edits to features that are not in conflict (and remember that in a normal situation and with good workflow design, conflicts should be the exception, not the rule!).

[Anonymous User]

Original User: Jamal432@gmail.com

Jamal, there are a few more things to take notice of:

Basically, in a comparison of any two versions, there are two types of feature edits to be distinguished:

- Those not in conflict
- Those in conflict

What happens with these feature edits?

Those not in conflict
If there is no conflict between edit version and target for a particular feature, any edit to a feature in the edit version will be automatically posted to the target.

Those in conflict
If there IS a conflict, the setting you choose for "conflict_resolution" (FAVOR_TARGET_VERSION or FAVOR_EDIT_VERSION), will determine whether the state of the conflicting feature in the target, or the state of the edit version will be maintained in the target after the reconciliation and post.

If you choose FAVOR_TARGET_VERSION, NO posting of the conflicting feature edit in the edit version will take place, and the target versions representation remains the same as it was.

If you choose FAVOR_EDIT_VERSION, posting of the conflicting feature edit in the edit version will take place, and the target versions representation will be replaced by the edit version.

So the "conflict_resolution" parameter of the "Reconcile Versions" tool only affects / concerns features that are in conflict. This setting does nothing for all the remaining edits to features that are not in conflict (and remember that in a normal situation and with good workflow design, conflicts should be the exception, not the rule!).

Many thanks Marco for the massive elaboration,

Please, consider the scenario in the screenshots below

[ATTACH=CONFIG]28310[/ATTACH], [ATTACH=CONFIG]28311[/ATTACH], [ATTACH=CONFIG]28312[/ATTACH]


The target geodatabase is editied (in the post stage) despite the fact that the �??conflict resolution�?� is set based on �??target version�?�

[MarcoBoeringa]

Many thanks Marco for the massive elaboration,

Please, consider the scenario in the screenshots below

The target geodatabase is editied (in the post stage) despite the fact that the �??conflict resolution�?� is set based on �??target version�?�

Jamal, if by this, you mean you hadn't expected feature 11 to move in SDE.DEFAULT because you set "FAVOR_TARGET_VERSION", than you are forgetting that you didn't edit feature 11 in the SDE.DEFAULT, you only edited feature 11 in the versions u1, u2 and u3.

Since you didn't edit feature 11 in SDE.DEFAULT, there is NO edit conflict for feature 11 between SDE.DEFAULT and u1 once you start reconciling. Hence the edit of feature 11 in version u1 is posted to SDE.DEFAULT, and feature 11 thus moves in SDE.DEFAULT.

If you want to see the other result as a test, namely a feature 11 that does not move with the edits in other versions, you will need to create a conflict by editing it in the SDE.DEFAULT as well, and setting "FAVOR_TARGET_VERSION", and than reconcile and post. This is what you did with feature 10, you moved it in SDE.DEFAULT. As a consequence, feature 10 in SDE.DEFAULT is in conflict with u1, and since you set "FAVOR_TARGET_VERSION", feature 10 remains as it is in SDE.DEFAULT after the reconciliation and post.

ArcGIS is behaving exactly as expected!