topic Re: Sequence of reconcile/post from multiple versions to default ArcSDE geodatabase, in Data Management Questions

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

JamalNUMAN — Sat, 08 Jun 2013 16:06:47 GMT

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

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

Anonymous User — Sat, 08 Jun 2013 22:33:37 GMT

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.

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

MarcoBoeringa — Sun, 09 Jun 2013 12:40:14 GMT

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

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

Anonymous User — Sun, 09 Jun 2013 20:06:15 GMT

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

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

MarcoBoeringa — Sun, 09 Jun 2013 21:12:39 GMT

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.

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

Anonymous User — Mon, 10 Jun 2013 13:09:24 GMT

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.

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

JamalNUMAN — Mon, 10 Jun 2013 19:28:13 GMT

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

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

MarcoBoeringa — Wed, 12 Jun 2013 08:51:10 GMT

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

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

Anonymous User — Thu, 13 Jun 2013 17:47:05 GMT

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

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

JamalNUMAN — Tue, 01 Oct 2013 07:56:03 GMT

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

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

MarcoBoeringa — Tue, 01 Oct 2013 17:14:58 GMT

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?

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

Anonymous User — Tue, 01 Oct 2013 19:15:05 GMT

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]

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

MarcoBoeringa — Wed, 02 Oct 2013 08:24:58 GMT

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.

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

Anonymous User — Wed, 02 Oct 2013 08:33:31 GMT

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.

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

Anonymous User — Sun, 06 Oct 2013 22:20:43 GMT

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]

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

MarcoBoeringa — Mon, 07 Oct 2013 07:09:42 GMT

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.

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

MarcoBoeringa — Mon, 07 Oct 2013 07:33:55 GMT

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

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

Anonymous User — Mon, 14 Oct 2013 18:01:13 GMT

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

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

MarcoBoeringa — Tue, 15 Oct 2013 05:33:46 GMT

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!

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

Anonymous User — Wed, 16 Oct 2013 18:23:48 GMT

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]