nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Common Practice of Versioning

EmilyLee

Hello GeoNet Community,

I am seeking for suggestions of a good use of versioning please. I am wondering if it is a common practice to version all feature classes (~100+ layers) in a geodatabase? But only some of them will be edited regularly, the others might be edited once a year. Also, if 90% of the time, only one editor would edit the layers, would it still be a good practice to version the layers just in case of the 10% of the time?

Thank you,

Emily

Find more posts tagged with

Accepted answers

All comments

EmilyLee

Thank you, Rebecca. This might be a good workflow for me.

EmilyLee

Hi Robert,

This might be a silly question- If the DEFAULT version is set to PROTECTED, then other versions cannot post to the DEFAULT version, correct? Is there a way that the editors cannot edit the DEFAULT version, but be able to post edits to DEFAULT version? So, the owner of the DEFAULT doesn't have to switch to each version and post the edits for them. Or is that what the '3-Level Version Tree' with a QA version is for?

Thanks again,

Emily

EmilyLee

Thank you, Derek! You're always famous at UC!

EmilyLee

Thank you, Dana! This is another great reason to do versioning!

EmilyLee

Thank you very much, Robert!

RebeccaStrauch__GISP

Also keep in mind that although the database is registered as versioned, that doesn't mean you always have to have child versions. If 90% of the time none of the files are needing edits, you can set up the security as Robert discussed, basically having it be read only for all but SDE account and/or the owner. Then when you are getting ready to make changes, create a version (only takes a few seconds) giving your designated edit the rights to edit. Do your necessary reviews of the data, and when ready to publish, do a reconcile and post so others will see the updates from default. If you know that it will be a while before you need to make anymore changes, you can always delete the child version after the reconcile/post and after an admin compress, you may even get back to state zero.

Personally, I would always recommend making changes thru a child version and not the default because it gives you the chance to reject conflicts if needed. That is not to say that I haven't made a quick, simple change directly to the default (for example a change to an attribute).

Also, take advantage of creating an historical markers that can basically show a virtual cooy of the database status at the time you made the connection.

DerekLaw

Hi Emily,

In addition to some of the good responses already, you might find this Technical whitepaper useful. While it is a bit old, its concepts are still good and applicable to versioned data management in an enterprise geodatabase:

Versioning Workflows Technical whitepaper

Hope this helps,

DanaNolan

The multiple-editor situation is not the only reason for using versions. Versions can provide some protections that allow you to not process changes, for example, until they are approved. I have had some annual updates to somewhat controversial data that could not be published anywhere until vetted. They were hidden in a version other than Default; I don't have references in standard maps to any version other than default.

When it is time to publish edits, posting changes is pretty foolproof, while, for example, keeping changes in a file GDB and bringing them into SDE might not work so seamlessly.

You can also back out changes or do other restores easily by getting data from other versions (not edited). On a day to day level, simply being able to use version-compare tools is useful when you are interrupted constantly as I am. Also, you can post at the end of/beginning of the day, so viewers don't see changes flashing at them while they are trying to work.

Robert_LeClair

Emily -

One thing you can do to prevent accidental editing of the DEFAULT version is to set it as PROTECTED. That way all authenticated users can connect to the geodatabase but cannot edit the DEFAULT version - only SDE can. Then you can make a child version of DEFAULT for your editors.

One way to get around users accidentally editing a version they're not supposed to is to configure their connection to point to only the version they're supposed to. Then when they activate the connection, they're on their version and do not have to change versions from DEFAULT to something else. That and setting DEFAULT to PROTECTED.

If you're data is stored in SQL Server, Oracle, PostgreSQL, etc., then you are configured for multi-user editing. ArcMap by default in set up for non-versioned editing so you have to change that after you register feature classes as versioned. The key is permissions on data - create an Editor Role, a Reader Role, etc. and assign users to those roles. The owner of data (feature classes, tables) then assigns the read/write permissions to the data.

The multiuser geodatabase requires good planning for security, editing, permissions, maintenance and more. It's a great workflow!

Regards,

Robert

EmilyLee

Robert,

Thank you very much for your response! It's great to have an expert in the community. 😃

I'm not sure why DEFAULT version editing is allowed when the layer is versioned. My concern is that people might forget to switch to their version and edit the DEFAULT version directly.

So, would you recommend agency not to version all their data unless they have to do multi-user editing on the data?

Thank you,

Emily

Robert_LeClair

Emily -

Great question! So if you have your vector data stored in a multiuser geodatabase, technically they're configured for non-versioned editing. If you registered a feature class as versioned, then it adds delta tables to that feature class for versioned editing. To further muddy the waters, when you create a new multiuser geodatabase there is only the DEFAULT version. If you want to make child versions of DEFAULT for editing, you can. I recommend reading the Versioning 101 Whitepaper - http://www.esri.com/news/arcuser/0110/versioning101.html - to understand the terminology. So you COULD have 100+ feature classes registered as versioned if you want to. And you COULD edit your data in the DEFAULT version. But would you want too? Probably not...

Not sure if this helps - I teach the Versioning class so can help out...

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.