Multiple Users Accessing Same SDE File

[Lake_Worth_BeachAdmin]

I am in charge of a SDE with my Municipality with a large amount of data over 300+ separate files. I have multiple departments that have access to this SDE with multiple users in each department. No users besides myself and one other (my associate) edit any information. Everyone else is only viewing the data (in ArcMap).

My problem is that when it comes time for myself or my colleague to make edits or perform file property changes (add domains etc.) to files, the files are being used by other users (usually more than one) which cause file locks.

I want to know how I can still make these edits/ file changes while other users are still viewing the files. 

I have proposed that when these file locks occur I ask the users to exit out of ArcMap the only issue is some users have very old PC's and the start-up time for these MXD's can be very long and asking them to boot off arcMap multiple times a day is not a reasonable request. 

It would be ideal for me to be able to make my desired edits while other users are reading the files and these files would update for the user once they exit out and reopen the file connection to the SDE. So basically while reading the file nothing changes (even though I made edits while they had the file open) until they close arcmap and re-open it. 

Any information at all regarding this topic is much appreciated!

[Lake_Worth_BeachAdmin]

Multiple versions as in what way? I have one for each department(that will be accessing the data), which will then get posted to myself and my college who will then decide to to post to the Default. Each Version will contain all files but respectively each department only works on their own files so it wouldn't overlap. (I think this is what you mean?)

[Lake_Worth_BeachAdmin]

What would be your ideal workflow for this situation seeing how you have a great deal of experience regarding this topic. (in reference to the image I posted above) I am curious to see. 

[Lake_Worth_BeachAdmin]

What would be your ideal workflow for this situation seeing how you have a great deal of experience regarding this topic. (in reference to the image I posted above) I am curious to see. 

[DerekLaw]

Hi Joseph,

Please review the contents of this Esri whitepaper which may help you decide which version workflow best meets your business workflow requirements. It's an older document, but its contents are still valid.

Versioning Workflows whitepaper

Hope this helps,

[Lake_Worth_BeachAdmin]

I already have, my boss wants to use the 3-level version tree which is what I illustrated the workflow above. (but each department gets its own level)

Just wondering if there was a better way to do this (my boss doesnt know much regarding this nor do II am the one learning this, working on it and implementing the changes) 

[JoeFlannery]

Joseph:

For our GIS "Instance" on the SQL Server in our shop, our DBA created two seperate DB users, one that has read/write/modify privileges and one that has read-only privileges. In ArcCatalog, I create two SDE connection files to the database (server name\instance, user name and password [using Database Authentication]) - one that our data editors use (the read/write/modify user) and one that data viewers use (read-only user). Match the appropriate SDE connection file with the user's needs.  We don't use versioning - it's too complicated and overkill for what we are doing.

[JacobBoyle]

I think you're on the right path overall, but I'd really simplify things greatly. I would just have one version off of default, called working, and a version off of working for each editor, point your reviewers to the working version, and any readers/web apps to default.   Then institute some kind of regular schedule for reconciling and posting between the versions.  IE... Editors post nightly to the working version, and the working version be set to post at a set interval (weekends) to default.

You're also going to want to consider historical versioning over this more traditional versioning workflow.  The place I work at currently, and oversee the SDE environment, we decided it was easier to implement time based historical versioning and just ensuring everything is setup as Registered as Versioned.  This means that everything is stored historically, and can be rolled back to any point in time since implementation.  

[JoeBorgione]

Multiple versions as in what way? I have one for each department(that will be accessing the data), which will then get posted to myself and my college who will then decide to to post to the Default.

I see five versions:  Each and every one will have to be reconciled and posted to sde.default.  That's more administrative work than I have time, energy, or interest in.  .  When I first started in the SDE environment in version 8.x, I had a version for every user.  It didn't take long for me to figure out it wasn't efficient and didn't provide any value.  But if it works for you, that's great; I don't claim to have all the answers, just the gray hair.

What would be your ideal workflow for this situation

Ideally?  Me on the beach in Mahahual Quintana Roo, Mexico, still drawing a pay check while my energetic assistant answers all the complaints and does the actual work.  All seriousness aside and beachwear not withstanding, what I do works for me, and may or may not work for you.  I have a much smaller operation with respect to data, and I have fewer users.  I use the enterprise versioned data model for data editing only.  Everything else, like published services, network analysis etc are done with file geodatabases that are child replicas of the enterprise gdb.

Best of luck.

[ChrisDonohue__GISP]

Joe Borgione 

Not to hijack the thread, but just out of curiosity do you have a workflow where you do editing in a File Geodatabase (copy of the Default feature class(es) that need to be edited), then use that to update Default in SDE?  I.E. instead of using Versioning?

Chris Donohue, GISP

[JacobBoyle]

That's completely possible, and I've done it in disconnected environments with much success.  This model can also be implemented with Feature Services pointing to SDE.  The end users are able to check out and check in a copy of the data for editing locally.