Recommended Workflow For Protecting the DEFAULT Version in Multiuser Geodatabse

246
5
11-14-2017 09:34 AM
Highlighted
New Contributor III

From the title of the question, you can guess that have a multiuser geodatabase with Oracle Enterprise RDBMS. The Version of the geodatabase is 10.4.1 and Oracle 11g.

We have over 35 data editors with the flat version tree, each user having their own version, editing the data that are responsible to maintain. We have set current access of DEFAULT Version to PUBLIC because each user can Reconcile and Post their edits to the DEFAULT Version. Now, there have been instances where editors have accidently deleted, edited the DEFAULT Version directly.

My first question: Is there a way to keep the DEFAULT Version protected and getting edited directly without changing its the Access from PUBLIC to PROTECTED?

My section question: Without using a backup of the Geodatabase, is there a functionality in multiuser geodatabase to quickly restore the geodatabase in case of disaster strikes (Missing Data in Default Version)?

Reply
0 Kudos
5 Replies
Highlighted
MVP Esteemed Contributor

My first question: Is there a way to keep the DEFAULT Version protected and getting edited directly without changing its the Access from PUBLIC to PROTECTED?

Not that I'm aware of; you are living dangerously if you allow the 35 editors access to sde.default.  However, to deploy a safer method you'll need to designate someone to perform the reconciles and posts, and in the mulit-versioned scenario that can be problematic:  even though each editor supposedly is editing in distinct areas, there may exist the potential for two editors to edit the same feature.  In the multi-versioned scenario there will be a conflict detected and the reconcile/post person needs to determine which to accept.  (if you automate the reconcile/post process, you'll just set a rule as to which conflict gets accepted: right or wrong..)

I was that guy and the database only had a dozen or so editors, each with their own version.  After struggling with the conflicts issue, I changed the edit-model to one 'Edits' version.  That way in the event a second edit was made to a feature, that last edit "stuck" and there was no conflict to deal with.  That worked well for my application, but obviously I cannot be sure it would work for you.

My section question: Without using a backup of the Geodatabase, is there a functionality in multiuser geodatabase to quickly restore the geodatabase in case of disaster strikes (Missing Data in Default Version)?

You really need to back up your data and know how to restore it.   Again, allowing 35 individuals access to sde.default is a disaster waiting to happen.

Highlighted
Esteemed Contributor

How about making the default version protected and creating a child version of default that each editor could then make a version off of.  In that way you can review and approve the changes to the child version of default before reconciling and posting that version to default.

Highlighted
MVP Esteemed Contributor

Sure.  Why not?  But some where in the process there may exist a conflict during the reconcile / post process: review and approve the changes to the child version.

 

As the dba, I had other things to do besides call around and figure out whose edit to keep.  Just sayin'....

Reply
0 Kudos
Highlighted
New Contributor III

Thank you for your reply, Michael! Yes, this idea crossed my mind once. With this workflow, someone (data admin) will have to be in charge of that child version (of Default). The shortage of manpower is another issue.   

Reply
0 Kudos
Highlighted
New Contributor III

Thank you for your reply, Joe! 

Reply
0 Kudos