topic Re: Common Practice of Versioning in Data Management Questions

Common Practice of Versioning

EmilyLee — Wed, 30 Nov 2016 16:31:09 GMT

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

Re: Common Practice of Versioning

Robert_LeClair — Wed, 30 Nov 2016 22:20:54 GMT

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

Re: Common Practice of Versioning

EmilyLee — Thu, 01 Dec 2016 22:22:27 GMT

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

Re: Common Practice of Versioning

Robert_LeClair — Thu, 01 Dec 2016 22:30:47 GMT

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

Re: Common Practice of Versioning

DanaNolan — Thu, 01 Dec 2016 23:04:59 GMT

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.

Re: Common Practice of Versioning

DerekLaw — Sat, 03 Dec 2016 04:57:53 GMT

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,

Re: Common Practice of Versioning

RebeccaStrauch__GISP — Sat, 03 Dec 2016 06:03:20 GMT

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.

Re: Common Practice of Versioning

EmilyLee — Mon, 05 Dec 2016 17:46:54 GMT

Thank you very much, Robert!

Re: Common Practice of Versioning

EmilyLee — Mon, 05 Dec 2016 17:47:49 GMT

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

Re: Common Practice of Versioning

EmilyLee — Mon, 05 Dec 2016 17:51:17 GMT

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

Re: Common Practice of Versioning

EmilyLee — Mon, 05 Dec 2016 18:09:30 GMT

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

Re: Common Practice of Versioning

EmilyLee — Mon, 05 Dec 2016 18:11:33 GMT

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

Re: Common Practice of Versioning

Robert_LeClair — Mon, 05 Dec 2016 18:36:36 GMT

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

Re: Common Practice of Versioning

EmilyLee — Mon, 05 Dec 2016 23:23:16 GMT

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