What is the benefit of “move edits to base” option that’s set for a versioned feature class?

[JamalNUMAN]

Why do we have the �??move edits to base�?� option,

I�??m wondering for which purposes the option of �??move edits to base�?� is offered! With this option, users are losing functions such as �??enable archiving�?�, for example.

[ATTACH=CONFIG]21313[/ATTACH]

Then in which cases this option (move edits to base) is useful?

Thank you

Best

Jamal

[AnthonyGiles]

Jamal,

When data is registered as versioned with the option to move edits to base, edits are automatically moved from the delta tables to the base tables when you save edits to sde.default or when you post edits in a child version to sde.default.

Saving edits in a child version of default does not cause edits to be moved from the delta tables to the base table.

This option is really designed to support nonversioned edits by third-party applications.

There is a good flow diagram here that helps you decide if that option would work with your workflow:

http://resources.arcgis.com/en/help/main/10.1/index.html#//003n000000t0000000

Regards

Anthony

[AsrujitSengupta]

Jamal,

As the ESRI WEBHELP clearly describes: " Checking this option causes edits that have been saved to the DEFAULT version, whether edited directly or merged from other versions, to be saved in the base (business) tables. Edits to other versions remain in the delta tables when you save.

This option is available for simple features only�??those that do not participate in a topology, network dataset, or geometric network. Therefore, if you open the Register As Versioned dialog box and find the move edits to base tables check box is unavailable, it means your dataset contains a topology, network dataset, or geometric network.

Regards,

[JamalNUMAN]

Jamal,

As the ESRI WEBHELP clearly describes: " Checking this option causes edits that have been saved to the DEFAULT version, whether edited directly or merged from other versions, to be saved in the base (business) tables. Edits to other versions remain in the delta tables when you save.

This option is available for simple features only�??those that do not participate in a topology, network dataset, or geometric network. Therefore, if you open the Register As Versioned dialog box and find the move edits to base tables check box is unavailable, it means your dataset contains a topology, network dataset, or geometric network.

Regards,

Thank you Anthony and Asrujit for the very useful answer.

1. Till now I couldn�??t figure out the justification for the use of the �??move edits to base�?� option. Why the user should do care about whether the edits are transferred DIRECTLY to the base table or not? What are the consequences?

2. If the �??move edits to base�?� is covered (function wise) by the �??NON-move edits to base�?� option, then why anyone should choose the �??move edits to base�?� option? Do anyone love to lose functions in this case?

3. By choosing �??move edits to base�?� one will be missing many functions (disadvantages):

a) Archiving
b) Topologies/network/geometric/fabric

4. What might be disadvantages of using the �??NON-move edits to base�?� option all the time?


Best

Jamal

[AndresCastillo]

Registering the data as versioned without the option to move edits to the base table is beneficial because the other option does not allow for conflict detection, nor replication.

See this:
http://desktop.arcgis.com/en/arcmap/10.4/manage-data/geodatabases/data-maintenance-strategies.htm

[JamalNUMAN]

This question is still valid in Pro 3.0.1. What is the benefit of enabling the “move edits to base” option for versioning?

Basically, the advantage of having a version is to avoid editing the production data and thus edits are performed in the version and transferred to the production with the “post” tool when required

[Bud]

We register as versioned because:

• We want undo functionality in an edit session. That's only possible with versioning -- undo functionality comes with all types of versioning.
  • We don't actually use named versions. We always edit the default version.
  • In other words, we don't actually care about versioning functionality (i.e. long edit transactions) -- other than the undo functionality.

We register with the option to move edits to base because:

• We access our data via SQL. The easiest and most performant way to access up-to-date versioned data with SQL is to use the "move edits to base" option. The edits get automatically posted to the default version. So the default version always has up-to-date info.

[JamalNUMAN]

In terms of feature class, the traditional versioning with or without enabling the “move edits to base” option is the same. Edits performed by any user (who has edits privileges) are transferred to parent immediately either way.

Can the difference only be felt at the level of SQL database? How?

[Bud]

If a user edits a named version, other than the default version, then I suspect those edits would not be visible in the default version (the feature class) via SQL until the user reconciles and posts the named version to the default version.

[Kevin_MacLeod]

Nice explanation Bud. For those coming across this thread, it sounds like in short, you do not want to enable the option.   Which is why it's off by default, presumably.

Jamal I can see we are in the same boat, trying to figure out Versioning.  Did you ever find out the answer to your last post?  You should not see edits in a parent or Default until you Post upward to the target, at least in my testing with 10.9.1.