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

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

[MarcoBoeringa]

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

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

[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

[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

[Anonymous User]

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

[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