nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Clip_265.jpg

Clip_264.jpg

Find more posts tagged with

Accepted answers

MarcoBoeringa

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!).

All comments

Kevin_MacLeod

@MarcoBoeringa , I understand your point of users editing different work areas of a feature class, or of only editing different layers altogether. However for various reasons that may not be realistic. A tool to systematically view Differences and Conflicts between two or three or more children, before posting to Default, would greatly assist in semi-automating QA/QC. For now the only thing I can think of, is to have an intermediate child Version to one-by-one post GrandChildren to, to see Differences and Conflicts. (Default->Child-> Grandchild 1, Grandchild 2, Grandchild 3)

It would be great if there was a way to view Differences and Conflicts between Children at the same level, before posting to Default. Or to any parent.

I posted a question before coming across this thread. https://community.esri.com/t5/data-management-questions/is-there-a-way-to-compare-between-multiple-child/td-p/1537009

Basically, seems like it's not possible? Someone posted some arcane SQL to do it but if it's not possible in a GUI I'll just muddle through by creating an intermediate version and one by one looking at Differences, which is the only way I can think of seeing differences, one by one, between multiple children, before posting all the way up to Default.

Ideally, 3 things would be possible:

1) ability to view differences and conflicts between child versions at the same level (child to child)

2) ability to accept/reject/modify in the Differences Panel one by one.

3) ability to Post only some feature classes, not all feature classes in the database, up Default or to a parent. Furthermore, ability to post only certain records (features) in a featureclass, based on an attribute. For example if I added a field marked 'approved' and then marked all the Posted features from Child 1 in Default as 'Approved'; then posted Child 2 with a filtering query, so only certain records in certain feature classes were Posted up from Child 2. I see the Conflict Filter tool in the toolbox and will experiment; hopefully that can exclude entire feature classes too.

JamalNUMAN

This question is still valid in ArcGIS Enterprise (Pro 3.0.1)

Not sure why the edits occurred on the child versions are posted to the parent based on the date the child versions created but not the date the edits occurred in each version

Consider the scenario below:

Assume that a parent version has 3 children versions ch1, ch2, and ch3 that are created respectively
Now, suppose that the same feature is edited by ch3, ch1, ch2 respectively
As the “post” is applied, then the parent versions will be edited based on ch1 despite the fact that last time editing has been performed was in ch2 version.

This means that parent is modified based on the DATE the versions created but not the DATE the last edit made (regardless on which child version)

My understanding is that the parent should take the last edits made regardless the child version this editing is made in

MajdoleenO_A__Awadallah

Hi all,

Thank you for the useful information you discussed, but after working on this issue, I found that the "reconcile versions" depends on the updated of the last created version. which is "rr" in the attached photo, and does not depend on the time or other factors. The edits of the version of "rr" are transferred to the resulted default ArcSDE geodatabase while the edits of versions of "mm"" or "nn" are not transferred to default ArcSDE geodatabase, this clarify that the reconcile depends on the last created version.

Best,

Majdoleen

Anonymous User

Original User: Jamal432@gmail.com

Jamal,

No, this isn't risky, it is a choice. A choice that you as the user consciously make or not. There is no "good" or "bad" here.

To make this more clear: let's for the sake of it assume there are two editors "A" and "B". "A" makes an edit to his version and saves at 10:05:34 AM. Now "B" makes a conflicting edit in his own version and saves at
10:18:56 AM. Now who made the right edit? Is it "B" because he saved the last? Or "A" because he had the right papers, and "B" was accidentally given the wrong dossier?

I hope you will agree there is no way to tell if A or B was right in case of a conflict, and certainly NOT based on something as arbitrary as a "save time". Only a review of what A and B did, and what paper sources or dossiers they used for the edits, might reveal who was right and who was wrong, so who made the error causing the conflict.

And even if there is no conflict at all, any edits in any version including the DEFAULT might be wrong, because who is telling you your employees are doing their job right? (of course, I hope they do!).

ArcGIS and the versioned editing environment does, of course - and logically - assume that any non-conflicting edits must be posted to the target based on the order of the save times / states, this is why the "edit versions" are listed in the recommended reconciliation order, the way they are visible in the Reconcile Versions dialog.

I do have the feeling that you keep forgetting that editing conflicts, in a healthy well designed workflow, should be the absolute *exception*. If the workflow of your organization causes hundreds of editing conflicts, no (semi-automated) tool anyone at ESRI can devise, will solve the mess with you leaning back in your chair watching it happen!

You should always ensure your workflows are good, than use reconciliation to fix the few errors left in a controlled and conscious matter.

This may also mean no batch reconciliation, but one-by-one reconciliation with review of someone with authority to make the decisions to solve the conflict (most likely after a short investigation to find out what went wrong, and what the right state of the features involved should be based on the latest information gathered).

Hi Marco,

I�??m really very thankful for the help you have offered. My understanding for reconcile/post of versions is much better now. I appreciate that you are sharing your experience in this field.

Best

Jamal

MarcoBoeringa

*If the type of conflict resolution is chosen to be �??in favor of edits�?� then the default.sde will be updated based on other versions in case of conflict! This is risky (screenshots below)

Jamal,

No, this isn't risky, it is a choice. A choice that you as the user consciously make or not. There is no "good" or "bad" here.

To make this more clear: let's for the sake of it assume there are two editors "A" and "B". "A" makes an edit to his version and saves at 10:05:34 AM. Now "B" makes a conflicting edit in his own version and saves at
10:18:56 AM. Now who made the right edit? Is it "B" because he saved the last? Or "A" because he had the right papers, and "B" was accidentally given the wrong dossier?

I hope you will agree there is no way to tell if A or B was right in case of a conflict, and certainly NOT based on something as arbitrary as a "save time". Only a review of what A and B did, and what paper sources or dossiers they used for the edits, might reveal who was right and who was wrong, so who made the error causing the conflict.

And even if there is no conflict at all, any edits in any version including the DEFAULT might be wrong, because who is telling you your employees are doing their job right? (of course, I hope they do!).

ArcGIS and the versioned editing environment does, of course - and logically - assume that any non-conflicting edits must be posted to the target based on the order of the save times / states, this is why the "edit versions" are listed in the recommended reconciliation order, the way they are visible in the Reconcile Versions dialog.

I do have the feeling that you keep forgetting that editing conflicts, in a healthy well designed workflow, should be the absolute *exception*. If the workflow of your organization causes hundreds of editing conflicts, no (semi-automated) tool anyone at ESRI can devise, will solve the mess with you leaning back in your chair watching it happen!

You should always ensure your workflows are good, than use reconciliation to fix the few errors left in a controlled and conscious matter.

This may also mean no batch reconciliation, but one-by-one reconciliation with review of someone with authority to make the decisions to solve the conflict (most likely after a short investigation to find out what went wrong, and what the right state of the features involved should be based on the latest information gathered).

Anonymous User

Original User: Jamal432@gmail.com

Jamal, you are still missing a point here, and I explained this in my last post. This is what is happening for feature 11:

1) Since in these last screenshots you posted, you don't edit feature 11, feature 11 isn't in conflict with u1. This means the edit of u1 will be posted to target SDE.DEFAULT.

2) Next u2 will be reconciled against target SDE.DEFAULT. Since feature 11 in SDE.DEFAULT now changed based upon the edit in u1, it now IS in conflict with feature 11 in u2! Since you set "FAVOR_TARGET_VERSION", the edit in u2 will be ignored and SDE.DEFAULT remains the same.

3) The same holds for u3, feature 11 in u3 is in conflict with the target SDE.DEFAULT, and hence the edit of feature 11 in u3 will be ignored / discarded too.

As a consequence, feature 11 in SDE.DEFAULT will be based on the edit of u1.

You will need to set "FAVOR_EDIT_VERSION" in case you want the edit of feature 11 in u3 to be incorporated in target SDE.DEFAULT.

As you can now also see, the status of being "in conflict" or not, can change during the batch reconciliation, as each edit version is reconciled and posted one after another...

Many thanks Marco,

This brings us back to the first question.

Why the ArcGIS starts reconciliation with u1 but not with u2 or u3. For example, if the system starts with u3 then feature #11 will be updated based on the location of the u3 but not based on the location of u1. (Sequence is still not clear for me)

In other words, I'm looking for the following behavior:

1. In case of conflicts: all should be updated based on the default.sde version
2. In case where there is no conflict: all should be updated based on the �??last save time�?� (in our case updating must be made based on changes on u3 but not u1)

Is that possible?

*If the type of conflict resolution is chosen to be �??in favor of edits�?� then the default.sde will be updated based on other versions in case of conflict! This is risky (screenshots below)

[ATTACH=CONFIG]28397[/ATTACH], [ATTACH=CONFIG]28398[/ATTACH], [ATTACH=CONFIG]28399[/ATTACH], [ATTACH=CONFIG]28400[/ATTACH]

1. I expect that feature #11 must be updated based on u3 (blue color) and thus THE SPATIAL LOCATION SHOULD GO TO THE �??BLUE�?� COLOR NOT TO THE RED

Jamal, you are still missing a point here, and I explained this in my last post. This is what is happening for feature 11:

1) Since in these last screenshots you posted, you don't edit feature 11, feature 11 isn't in conflict with u1. This means the edit of u1 will be posted to target SDE.DEFAULT.

2) Next u2 will be reconciled against target SDE.DEFAULT. Since feature 11 in SDE.DEFAULT now changed based upon the edit in u1, it now IS in conflict with feature 11 in u2! Since you set "FAVOR_TARGET_VERSION", the edit in u2 will be ignored and SDE.DEFAULT remains the same.

3) The same holds for u3, feature 11 in u3 is in conflict with the target SDE.DEFAULT, and hence the edit of feature 11 in u3 will be ignored / discarded too.

As a consequence, feature 11 in SDE.DEFAULT will be based on the edit of u1.

You will need to set "FAVOR_EDIT_VERSION" in case you want the edit of feature 11 in u3 to be incorporated in target SDE.DEFAULT.

As you can now also see, the status of being "in conflict" or not, can change during the batch reconciliation, as each edit version is reconciled and posted one after another...

Anonymous User

Original User: Jamal432@gmail.com

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!

Thank you very much Macro for efforts for explaining the precise behaviors of versions as they are reconciled/posted

It is very clear now.

One behavior is still missing. I need the conflict to be resolved on favor of target (default.sde) but based on the �??LAST SAVE TIME�?� of all other versions!

1. I expect that feature #11 must be updated based on u3 (blue color) and thus THE SPATIAL LOCATION SHOULD GO TO THE �??BLUE�?� COLOR NOT TO THE RED

2. I expect that feature number #10 will be updated based on default.sde and thus the spatial location must go to the �??black�?� color (this is OK as the edits are controlled by the target version)

Please, have a look on the screenshot below:

[ATTACH=CONFIG]28374[/ATTACH], [ATTACH=CONFIG]28375[/ATTACH], [ATTACH=CONFIG]28376[/ATTACH], [ATTACH=CONFIG]28377[/ATTACH]

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!

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�?�

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.

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]

Reconcile_Post_order.zip

Clip_174.jpg

Clip_177.jpg

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.

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: 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]

Clip_143.jpg

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?

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

Original User: Jamal432@gmail.com

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

Thank you Marco for the comprehensive answer. The mechanism of versions is clear now

I�??ll be reading the documents that you have already recommended.

Best

Jamal

MarcoBoeringa

What I wanted to highlight here is that the order of versions when reconciled/posted with the parent is determinant!

In my previous example, if the first version is U2 and the second version is U1 then feature 10 will be deleted from the target. Correct?

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

JamalNUMAN

Jamal:

From this Help page:

"If you resolve conflicts in favor of the edit version, all conflicting features in the current edit session take precedence over conflicting representations in the target version."

1) You delete feature 10 in version U1
2) You start batch reconciliation and posting with the option "in favor of the edit version" as per your screenshot.
2) Reconciliation and posting of version U1 takes place, where feature 10 is deleted from the target database, no conflicts are detected in this phase.
4) Now reconcilation and posting of version U2 takes place, again "in favor of the edit version". A conflict is detected. U2 has the original feature 10 with an edit to its attributes, but this feature is deleted from the target. Since it takes precedence over the target version, where the feature is deleted, feature 10 is posted back to the target, including the attribute edit done in feature 10.

And yes, the deleted feature in version U1 is back...

Jamal, if you want detailed control over each conflict, you should review any edits manually, not run a "batch reconciliation" on multiple versions. ArcGIS has all these tools specifically for this reason: to allow you to make a good judgement of the conflict by thoroughly reviewing it.

As to best practices: multi-user edit conflicts are allowed and reconciliation supported in ArcGIS, but this doesn't mean you should be lax on good working practices. Well designed work flows and good work orders should always try to avoid conflicting edits as much as possible to avoid excess work in the conflict detecting & reconciliation.

Many thanks Marco and Leo for the help. This is quite useful

What I wanted to highlight here is that the order of versions when reconciled/posted with the parent is determinant!

In my previous example, if the first version is U2 and the second version is U1 then feature 10 will be deleted from the target. Correct?

Best

Jamal

Anonymous User

Original User: ldonahue

It all boils down to adds or deletes. Deleting is deleting, but updating an attribute is an add. And until your last post, I wasn't aware you had two users editing the same feature. In that case, order is important, but you won't catch it in this particular example if you are reconciling/posting in a batch process.

MarcoBoeringa

Then why the edits of the version of u1 are not transferred to the resulted default ArcSDE geodatabase while the edits of version of u2 are transferred to default ArcSDE geodatabase?

Jamal:

From this Help page:

"If you resolve conflicts in favor of the edit version, all conflicting features in the current edit session take precedence over conflicting representations in the target version."

1) You delete feature 10 in version U1
2) You start batch reconciliation and posting with the option "in favor of the edit version" as per your screenshot.
2) Reconciliation and posting of version U1 takes place, where feature 10 is deleted from the target database, no conflicts are detected in this phase.
4) Now reconcilation and posting of version U2 takes place, again "in favor of the edit version". A conflict is detected. U2 has the original feature 10 with an edit to its attributes, but this feature is deleted from the target. Since it takes precedence over the target version, where the feature is deleted, feature 10 is posted back to the target, including the attribute edit done in feature 10.

And yes, the deleted feature in version U1 is back...

Jamal, if you want detailed control over each conflict, you should review any edits manually, not run a "batch reconciliation" on multiple versions. ArcGIS has all these tools specifically for this reason: to allow you to make a good judgement of the conflict by thoroughly reviewing it.

As to best practices: multi-user edit conflicts are allowed and reconciliation supported in ArcGIS, but this doesn't mean you should be lax on good working practices. Well designed work flows and good work orders should always try to avoid conflicting edits as much as possible to avoid excess work in the conflict detecting & reconciliation.

Anonymous User

Original User: Jamal432@gmail.com

Hi Jamal,

I'm still on 10.0, but the concept is the same.

Whether you reconcile Sammi or Reda's version first to default doesn't matter if they are both children of the parent default version. If there are conflicts, the reconcile/post process will tell you about them and you can specify which version to favor or manually review the conflicts.

However it is best to reconcile the parent/child line in order, based on which user owns/created the version.

You should be able to reconcile/post any of those child versions against default in any order. if there are conflicts, the process will inform you about them.

Thank you Leo for the help,

To better explain the issue, please consider the scenario below

1. Two users (u1 and u2) are added to an ArcSDE geodatabase

2. Each user has created his version form the default ArcSDE geodatabase

[ATTACH=CONFIG]25160[/ATTACH]

3. The user �??u1�?� edits the data and deleted the feature below

[ATTACH=CONFIG]25161[/ATTACH]

4. The user �??u2�?� edits the same feature (the feature deleted from the version created by u1) and change one of the attribute values

[ATTACH=CONFIG]25162[/ATTACH]

5. These two versions are reconciled/posted with the default ArcSDE geodatabase with the settings below

[ATTACH=CONFIG]25163[/ATTACH]

6. The deleted feature according to the version of u1 is not deleted from the resulted default ArcSDE geodatabase!

[ATTACH=CONFIG]25164[/ATTACH]

Then why the edits of the version of u1 are not transferred to the resulted default ArcSDE geodatabase while the edits of version of u2 are transferred to default ArcSDE geodatabase?

Best

Jamal

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?

Jamal,

I think Leo covered it mostly, but ultimately, the exact time edits were saved determines which edits preferentially should be saved to the DEFAULT. Like Leo said, the conflict resolution options will allow you to see any conflicting edits, and allow you to make a judgement on which edits are favoured over others.

If users are editing completely different areas (e.g. Sami is editing municipality Nablus, and Reda is editing Hebron), and consequently no conflicts are to be expected, than the whole point of reconcile order becomes mute and non-consequential in terms of reconciliation.

I also recommend you to read:
Versioning 101
Essential information about ArcSDE geodatabases
By Derek Law, Esri Product Management

And these pages by SPP Innovations:
Versioning for Dummies: Part 1
Versioning for Dummies: Part 2, the State ID
Versioning for Dummies - Part 3: Reconcile, Post, and Compress...

Anonymous User

Original User: ldonahue

Hi Jamal,

I'm still on 10.0, but the concept is the same.

Whether you reconcile Sammi or Reda's version first to default doesn't matter if they are both children of the parent default version. If there are conflicts, the reconcile/post process will tell you about them and you can specify which version to favor or manually review the conflicts.

However it is best to reconcile the parent/child line in order, based on which user owns/created the version.

You should be able to reconcile/post any of those child versions against default in any order. if there are conflicts, the process will inform you about them.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.