Common Practice of Versioning

EmilyLee · ‎11-30-2016

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

Robert_LeClair · ‎11-30-2016

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

EmilyLee · ‎12-01-2016

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 · ‎12-01-2016

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 · ‎12-05-2016

Thank you very much, Robert!

EmilyLee · ‎12-05-2016

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

Robert_LeClair · ‎12-05-2016

Hi Emily -

No such thing as a silly question especially with versioning. You are correct that if DEFAULT is set as PROTECTED, then only the owner (SDE in this case) can edit (i.e. post) to it. There is no way to enable the post command/GP tool by other users if DEFAULT is set as PROTECTED. This is not such a bad thing though as it prevents unauthorized edits making it to the DEFAULT version. At a minimum, I would create a version tree as follows: DEFAULT (owned by SDE/Protected), child version of DEFAULT called QAQC (owned by GIS Manager/Protected), one or more child versions of QA called (EDIT1, EDIT2 or similar - could be departments like PLANNING, TRANSPORTATION, etc.) (owned by editors/Public).

This workflow does "complicate" things somewhat as only the GIS Manager can post to QAQC unless that version is set to PUBLIC and only SDE can post to DEFAULT. But it does keep edits "reviewable" on a few tiers so by the time the edits get to DEFAULT, you know they're correct.

Hope this helps!

Robert

EmilyLee · ‎12-05-2016

Thank you very much, Robert. I have a clear idea now.

DanaNolan · ‎12-01-2016

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.

EmilyLee · ‎12-05-2016

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