Select to view content in your preferred language

Migrating From Traditional Versioning to Branch Versioning

1991
2
Jump to solution
01-19-2023 01:59 PM
DavidSolari
Occasional Contributor III

I've got a table setup with traditional versioning + archiving and I'm planning to move it to branch versioning. Other than compressing everything out of the delta tables I'm not too sure how to proceed. Can you just disable versioning and then enable it again through a branch connection? Will that handle the "_H" archive table or will I need to transform that into the branch format? I'm willing to work with SQL Server directly for whatever's required, just wanted to see if anyone has tried this before.

0 Kudos
1 Solution

Accepted Solutions
DavidSolari
Occasional Contributor III

I'll leave some notes here for anybody who stumbles into this from a web search.

  • With Traditional Versioning and Archiving enabled, the current state of the feature class is tracked in the usual business + delta table combos. If you crack open your RDBMS there'll be a "_H" table which stores a full archive of every change that made it into DEFAULT. This is handy as the usual methods of fully compressing a versioned table seem to fall apart if archiving is enabled.
  • If you disable archiving, there's an option to  keep the archive. The table has the same "_H" name but it's logically detached from the main table. This seems to make full compression possible again.
  • Disabling versioning from this point leaves behind the business table with the final state of DEFAULT.
  • Enabling Branch Versioning creates the expected table schema and doesn't fiddle with the old archive table.

With this info the transitional workflow appears to be:

  1. Kick everyone out of the DB, stop every relevant web service etc. etc.
  2. Get the DEFAULT version to the desired state and blow out all child versions.
  3. Disable archiving and confirm the presence of the "_H" table.
  4. Disable versioning.
  5. Truncate all data.
  6. Enable Branch Versioning.
  7. ETL the "_H" table into the new schema, this will include the previously truncated data.

I can't guarantee anything so talk to your ESRI rep if you're migrating a critical dataset and keep a working backup on hand.

View solution in original post

0 Kudos
2 Replies
DavidSolari
Occasional Contributor III

I'll leave some notes here for anybody who stumbles into this from a web search.

  • With Traditional Versioning and Archiving enabled, the current state of the feature class is tracked in the usual business + delta table combos. If you crack open your RDBMS there'll be a "_H" table which stores a full archive of every change that made it into DEFAULT. This is handy as the usual methods of fully compressing a versioned table seem to fall apart if archiving is enabled.
  • If you disable archiving, there's an option to  keep the archive. The table has the same "_H" name but it's logically detached from the main table. This seems to make full compression possible again.
  • Disabling versioning from this point leaves behind the business table with the final state of DEFAULT.
  • Enabling Branch Versioning creates the expected table schema and doesn't fiddle with the old archive table.

With this info the transitional workflow appears to be:

  1. Kick everyone out of the DB, stop every relevant web service etc. etc.
  2. Get the DEFAULT version to the desired state and blow out all child versions.
  3. Disable archiving and confirm the presence of the "_H" table.
  4. Disable versioning.
  5. Truncate all data.
  6. Enable Branch Versioning.
  7. ETL the "_H" table into the new schema, this will include the previously truncated data.

I can't guarantee anything so talk to your ESRI rep if you're migrating a critical dataset and keep a working backup on hand.

0 Kudos
SU00861536
New Contributor III

Hi @DavidSolari ,

I am also working on similar requirement to migrate data from traditional version to branch version with Archive History of insert, update, deleted features.

Existing Geodatabase (SQLServer) Traditional Versioning  are managed in FeatureClass_H, now we want to migrate existing feature classes to newly created branch enabled versioned dataset. 

Our requirement to migrate the archive history of feature class from traditional version to branch version without any relation breaks.

We are doing below steps :

1. ArcGIS Pro, export the existing traditional version feature class archive data into GDB.

SU00861536_2-1675352205619.png

 

2. Create a new enterprise geodatabase, enable branch version.

3. Import the exported data into branch enabled feature dataset.

4. After importing, mange geodatabase functionality throwing the error.

SU00861536_1-1675351414848.png

 

Request @DavidSolari  @JFarmer  to help me in migration from traditionally enabled versioned archive data into branch enabled versioned feature class without any data loss.

  #BranchVersiong #GeoDatabse #Migration

 

0 Kudos