topic Re: Reconciling Traditional Versioning (not sent to base) in Data Management Questions

Reconciling Traditional Versioning (not sent to base)

CodyPatterson — Fri, 16 Feb 2024 15:51:07 GMT

Hey All,

I was curious what would be the best way to reconcile changes to our database? We have created a replica that will take from parent and deliver to child, and we will synchronize as goes.

We would like the view to be applied to the default record that it is taken from, but I'm not sure how that is done, I found the reconcile versions geoprocessing tool, but I'm not sure that's exactly what I'm looking for.

The main goal is to run a tool or script, and then see our SQL database show all version changes on a single dataset, the parent, and then continue using views for the version management.

We're using Enterprise 11.2 geodatabase.

Thanks in advance!

Re: Reconciling Traditional Versioning (not sent to base)

MarceloMarques — Fri, 16 Feb 2024 16:22:34 GMT

@CodyPatterson - the documentation shall answer your questions.

Reconcile and post edits to a traditional version—ArcGIS Pro | Documentation

Using Python scripting to batch reconcile and post traditional versions—ArcGIS Pro | Documentation

Re: Reconciling Traditional Versioning (not sent to base)

CodyPatterson — Fri, 16 Feb 2024 16:24:50 GMT

Hey @MarceloMarques

So in this case, if I had for example a state table, and then a state view due to traditional versioning, I could use this documentation to write the view back onto the table? I just want to be sure before I continue, but I appreciate the documentation!

Cody

Re: Reconciling Traditional Versioning (not sent to base)

MarceloMarques — Fri, 16 Feb 2024 16:49:29 GMT

@CodyPatterson

Traditional version scenarios—ArcGIS Pro | Documentation

Let me try to clarify. The ArcGIS Traditional Versioning when enabled on a Featureclass or Table it creates 2 new tables called Delta Tables, the A table for Adds and the D table for deletes, it also creates the multi-versioned view. Hence, you have the Base Table of the Featureclass or Table, the A table, D table and the multi-versioned view.

Then, you configure and work with the Geodatabase Replication, once you synchronized the data in the database child replica version, you can then run the reconcile and post to bring the edits into the sde.default version.

You also need to run the "Geodatabase ArcSDE Compress" often, at least once a week, and in a busy geodatabase with lots of edits you need to run the sde compress daily.

Compress (Data Management)—ArcGIS Pro | Documentation

How To: Successfully Compress the Geodatabase (esri.com)

How To: Automate Reconcile, Post and Compress Processes (esri.com)

Note, the sde compress is very important to be executed often and it moves the rows from the delta tables to the base table. For more information about sde compress I suggest you looking the documentation, but there is a good training class that I listed below that explains the sde compress in detail.

It is also recommended that you gather new database statistics at least once a week, and in busy geodatabases with lots of edits you gather new statistics daily. You will also need to rebuild indexes often, once a month, and in a busy geodatabase rebuild indexes once a week.

Enterprise geodatabase maintenance tasks—ArcGIS Pro | Documentation

About multi-versioned views. We use the multi-versioned view to edit the data in geodatabase traditional versions via SQL statements.

What is a versioned view?—ArcMap | Documentation (arcgis.com)

These are the recommended training.

Deploying and Maintaining a Multiuser Geodatabase | Esri Training Instructor-Led Course

Implementing Versioned Workflows in a Multiuser Geodatabase | Esri Training Instructor-Led Course

I hope this clarifies.

Re: Reconciling Traditional Versioning (not sent to base)

CodyPatterson — Fri, 16 Feb 2024 16:50:44 GMT

Hey @MarceloMarques

This looks like what I needed, I appreciate the information and documentation greatly! We definitely have lots of edits a day, more than likely 5000+ if that could be classified as a lot, so we'll have to more than likely compress as well.

I appreciate your help!

Cody