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!

[Robert_LeClair]

Geodatabase Replication would be a good option for this scenario.

[JoeBorgione]

Nope.  I only go one way from enterprise TO fgdb. I am not aware that a FILE gdb can be replicated.

As Jacob points out, you can do that in a disconnected environment which is something I've never tried and a little different than the more traditional parent to child replication that I use; I have used two-way replication between an enterprise gdb and personal sde.

[edited to make sense...]

Jacob Boyle‌

Robert LeClair‌

[Robert_LeClair]

You can create a check-out, check-in replica where the child replica is a single user geodatabase (Access or File), do the edits in the child replica, and check it back into the parent replica on the SDE side.

You are correct that a file geodatabase cannot be replicated FROM...the initiating process of replica creation starts with a multiuser geodatabase (SDE)

[RebeccaStrauch__GISP]

Everything else, like published services, network analysis etc are done with file geodatabases that are child replicas of the enterprise gdb

And I'd like to add, for us, most of this access, including services, is done from a FILE gdb,not SDE.  In fact, what my users see is a copy of the data, in a fgdb, that I repackage into more user friendly and more focused feature classes..most done need or care to see the fields or all the records from our default SDE databases.

re: versioning workflow with multiple child versions for editing ...make sure you at least "reconcile" often.  That is, pull down any changes that have been posted to the parent.  Waiting too long to do this, just because they changes in "your" child version do need to be posted yet, can cause many headaches....especially if you are using topology rules.  we waited too long on one of out (don't post for 6 months) ad even though the changes were not in the same geographic location, it still cause time to verify the things that were pulled down (we do use topo rules).

[NickHetrick]

2 way or 1 way replication is the solution that I use in my environment seems to work best. Implementing versions will still have schema locks and version management is much more of a pain depending how it is setup and not managing versions properly causes performance and data consistency issues which is a common problem I see often people wonder why there SDE performance is terrible when they have a blocking version that is 5 years old. Replication can be setup to where it is automated with less oversite I get a report every time replication completes and I run it nightly as scheduled task as well as blocking all connections so I can be confident no users or services are hitting the database. Way more time saving than making sure if a person has properly closed out a named version. I have had some great success with replication but there are pitfalls such as a replica version getting corrupted but it is fairly easy to fix by rebuilding the replica also attachements have messed up replication due to size . Changes to database objects should be scripted and then done within a maintenance window so users are not in the system and all services can be stopped so there are no locks on the database. Having them scripted in python is fairly easy and can really shorten your maintenance window as opposed to doing it manually.  

[Lake_Worth_BeachAdmin]

Can you point to some documentation that supports this method. I cant seem to find much for replication and using arcpy to automate this task. The entire workflow seems like it would cause less of a headache and intrigues me.