Version and editing management

1357
9
05-31-2012 03:20 PM
Waan
by
Occasional Contributor
Hello all

We're instituting a fairly simple "3-tier" versioned editing environment for a project of ours. After trying out a few version configurations, we've tentatively settled on the following:
Default "parent"
QA "child" (1, from Default)
editors' "grandchildren" (4, each from QA)

Our permissions are as follows:
Default - private (only SDE/DBO can view and edit)
QA - protected (master-editor has full rights)
editors - protected (each various editor creates their protected version from the QA parent version)

The idea is that someone (me!) serves as a master-editor to verify edits before posting each editor's version to QA. Then the administrator posts the QA edits to Default. This way we have an intermediate step between the editors and the Default version so that bad/incorrect edits don't accidentally make it to Default. None of this is original thinking as it's been described in numerous ESRI documents.

In our prior two-tier design (1 Default parent, 4 editors' children), we ran in to a situation where an editor made about ~40,000 deletions, of which ~700 were incorrect and needed to be recovered. Since no other editors had touched any of these ~700 features, no conflicts were detected and hence no flags were raised before these made it to Default. Fortunately I had an old version that hadn't recently been reconciled/posted, used the "Version Changes" tool to figure out which ~700 features had been accidentally deleted (plus a few more that had been legitimately edited), made a mass edit to all these features (a tiny nudge in this case), and then, when I reconciled with Default, used the Conflict Manager to go one-by-one through all 700 edits to determine which needed to be recovered or legitimately deleted. This is what caused us to move toward the three-tier design.

Since I don't want to do this again, my questions have to do with the actual mechanics of checking and confirming/rejecting edits between the QA version and the editors' versions. So far I've been unable to find the specifics of this in ESRI documentation.

1) Am I correct in understanding that since the QA version is protected, editors are unable to post their edits to QA--only reconcile?
2) Since I'm the owner of the QA version, the "Version Changes" tool is super useful to determine which edits have been made among the various editors' versions relative to their parent version (QA). However, I'm looking to combine the all-seeing "Version Changes" tool with the functionality of the "Conflict Detection Manager"--basically the capability to review and accept/reject each edit regardless of whether it conflicts. Is there any way to do this? The other alternative I can think of is using "Version Changes" to compare QA and editor versions, identify any bad/questionable edits, and then alert the editor to correct any potential errors in their work ... but the reporting abilities of "Version Changes" seem limited and I would greatly prefer a simple yea/nay/reject type of tool like the Conflict Detection Manager.
3) While I've found the ESRI documentation quite helpful (especially in comparing pros and cons of different versioning strategies--nice job), I'd be interested to hear about others' failures, success, and lessons learned with various versioning designs. Part of the catch here is that we have to use the SDE administrator to post from QA to Default--his time is limited, so if we started duplicating this design for other agency projects it could be a real hassle for him. As a workaround, he's given me an SDE connection using his admin authentication--but this seems a bit dicey since it might give too much power to personnel inexperienced with managing SDE (e.g. ... me!). Are we missing something? Are there more ways to assign users rights and roles--for example, one SDE administrator, several "super users" with read/write/load abilities, and dozens of users?

Thanks in advance.

-W
0 Kudos
9 Replies
JoeBorgione
MVP Emeritus
I just have to ask; is the 'butcher' still working for you?  700 deletions....  :mad:

I guess I'm lucky that I don't deal with such large numbers of edits or editors.  What comes to mind is perhaps your workflow could include comparing the individual editor-versions with the mid-level version and/or sde.default prior to reconciling and posting.  Without knowing what type of data you are working with, maybe a visual inspection is all you need, or maybe you need to get an actual count of features for each.  I use a trigger on the sql end that records the login of the person making the edit and the date of the edit; that has saved me more than once!  Backups & restores can be an administrators best friends.

Not much, but I hope this helps-
That should just about do it....
0 Kudos
CherylCleghorn
Esri Contributor
Warren

There is an alternative workflow in which you (the master-editor) can create a temporary version from the editor's version and perform the reconcile/post with QA. Once you are finished with your rec/post it is important for you to delete your temp version AND the editor to delete their version, then recreate their version from QA. Please contact Support Services so that they can walk you through these steps to ensure you completely understand the workflow. If the editor does not delete and recreate his/her version after you reconcile and post, but rather continues editing from that same version, you will be back to square one; in fact you could find yourself running into unexpected conflicts.

Regards
Cheryl
0 Kudos
Waan
by
Occasional Contributor
Figured I should follow-up to this thread for future reference.

Received a helpful email from Rudy P. at ESRI in response to my questions below. In short, there is currently no tool or technique to combine the conflict detection manager and the version changes tools ... as the "power user" and the one with all the permissions, I can't simply accept or reject any edit. I still need to identify and check the edits using version changes and/or other tools (see next paragraph) and, if I find any problems, communicate them to the editor and get them corrected. I should mention that reverting to a state offers one way to undo a bunch of bad edits--but undoes the good ones as well so isn't ideal.

Rudy pointed me toward a free script in the Resource Center. I've found it stable, easy-to-use, and helpful (if not a 100% solution): "Show Edits Since Reconcile" at http://resources.arcgis.com/gallery/file/geodatabase/details?entryID=71D19CFA-1422-2418-7F7C-60E3043...
It's similar in concept to the "version changes" tool but I find it quite a bit more useful for checking others' edits and/or any and all differences between a child and parent version.

The "three-tier" versioning design has worked okay so far, though there is a bit of extra overhead: generally one person is assigned to post from the editors' versions to QA, thence on to Default. If that person is gone, busy, etc., this can create an ever-growing backlog of edits to filter up the pyramid of versions. Some sort of reconcile/post schedule needs to be worked out; alternately, these duties need to have backup from others knowledgeable with the tools and workflow. One more thing: there is a 5-20 minute period between me checking edits and then going on to post the version to QA. In that time it's possible an editor could make a slew of accidental edits (e.g. mass deletion) which I could inadvertently propagate to the parent version. Just an FYI ... either have them stop editing while you check/post or perform these tasks at off times.

-W
0 Kudos
KarlWilson
Occasional Contributor III
there is currently no tool or technique to combine the conflict detection manager and the version changes tools ... as the "power user" and the one with all the permissions, I can't simply accept or reject any edit. I still need to identify and check the edits using version changes and/or other tools (see next paragraph) and, if I find any problems, communicate them to the editor and get them corrected.


I'm new to the whole versioning thing, but it seems to me that the QA person is severely limited by not being able to actually review (i.e. accept/reject/amend) edits whilst looking at the changes between versions.

Is there a best practice approach for dealing with bad edits? - Or does the QA person have to visually check all the changes, make a note of any issues and then contact the person responsible?

Rudy pointed me toward a free script in the Resource Center. I've found it stable, easy-to-use, and helpful (if not a 100% solution): "Show Edits Since Reconcile" at http://resources.arcgis.com/gallery/...C-60E304332809


I notice that this hasn't been updated for 10.1.
0 Kudos
KarlWilson
Occasional Contributor III
I have now tried the Data Reviewer extension, and this gives me a bit more functionality by allowing me to browse through the results of the "Version Differences" tool, and make amendments directly to these affected features in the main map view.

In order to see any deletes between versions however, I need to write the results to the Reviewer Table. From here I don't see any way of rejecting a delete / resurrecting a feature that has been incorrectly deleted.

So if somebody deletes the wrong feature in one version and saves their edit, how do intercept this error before posting it to the DEFAULT version?
0 Kudos
Waan
by
Occasional Contributor
I don't know that there is any simple way to catch editors' deletions right away. As far as I know, there are several ways to recover a deletion after the fact. However, if edits are being scrutinized as part of a sophisticated versioning scheme, it makes more sense (and is likely less time-intensive) to catch and correct these prior to reconciling/posting. It'd be great to hear from some DBAs about how they are or aren't handling this.
0 Kudos
KarlWilson
Occasional Contributor III
If you edit a feature in one version, and delete it in the other, the Conflicts dialog will let you choose which version to keep.

So the functionality effectively already exists to intervene and stop a feature being deleted, it just needs to be extended to cover non-conflict changes. The logical place to put this would be in the Version Changes dialog.

In the meantime, perhaps you can force a conflict by updating a single (redundant) attribute across all features in the target version. Then if a feature is deleted in the edit version it will be in conflict and allow you to review it.

However you could end up having to click away at the Conflicts dialog quite a lot to review all the changes one by one (it's not possible to select multiple!).
0 Kudos
KarlWilson
Occasional Contributor III
There's an idea that roughly covers this topic that could do with some votes:
https://c.na9.visual.force.com/apex/ideaView?id=08730000000btEU&mc=0

Although I may submit a new idea later that is a bit more comprehensive, once I've learnt a bit more...
0 Kudos
KarlWilson
Occasional Contributor III
These ArcGIS Ideas links can be a bit funny, try this instead:
http://ideas.arcgis.com/ideaView?id=08730000000btEUAAY
0 Kudos