AnsweredAssumed Answered

Handling Schema Changes for Enterprise SDE with Multiple Versions and Replicas

Question asked by N.Alexandrou on Dec 21, 2016

We have a production EDIT sde geodatabase with multiple QA/QC versions, with check out replica's of those and other versions. Everything is working fine. Occasionally I will need to make a schema change for a department. I will usually make the change to the DEFAULT version, and push the schema change out via import/export schema change geoprocessing tool (I do this every Friday, off-hours).

 

As of late, a main user of GIS in one of our departments has been demanding that they needs Admin privs to the full EDIT db because they need to be able to make schema changes whenever they like. (they really don't, they need to make them once a week at best).

 

I've tried working with them to establish a Change management type system where changes are made Fridays off-hours, and they are still hesitant. I told them it is really not best practice for end-users to make schema changes to any version, given that they will be making them during business hours which locks all other departments out of all versions and replicas, and that they don't know what to do after the schema change to make sure all versions and replicas continue to sync properly. Plus no one has the ability to do anything to DEFAULT other than the gdb admin, since it is protected anyway. They're not going to get elevated priv's, because they will mess something up and it will ultimately fall on me.

 

Curious what everyone else is doing? I think if she gives me the changes she needs, I can add them to a standard script that calls the AddValueToDomain or TableToDomain (append) tools and schedule it to run Saturday nights.

 

What do you think?

Outcomes