I am interested in possibly replicating one of our enterprise geodatabase and have a few questions on the process.

[MatthewBeal]

Right now, we have one main enterprise database that has all of our data on it. It is using the old LGIM structure. There are probably around 75 feature classes of varying sizes stored on it. Most are fairly small, however. Largest feature class is probably a point address file with ~40k addresses in it followed by a parcel file with ~30k parcels. 

My goal is to have the current version that our entire organization (including editors) is connected to act as a "Read-only" version. I want to clone it and make that clone the editing environment for our editors. I'd then like to have that edit version overwrite the read-only version on a schedule basis (ideally nightly). 

First of all, is this a practical workflow with an enterprise database of this size? I have no idea what the limitations for replication are. I have no idea how long it would take for it to overwrite the entire database and I can't find any resources that discuss that. If that isn't practical, are there any other alternatives?

Second, assuming it is feasible, are there any pitfalls to this method? 

I appreciate any help that you can provide!

[George_Thompson]

Initial thoughts:

- Why not just have a role that is read-only and use that for the people who are not editing?

- Are you looking to get away from the older LGIM model / schema?

- You could have the editors and viewers in the same Enterprise Geodatabase working at the same time

- Is there reason that you are thinking about "cloning" it to create the second "editing" EGDB?

- You could set up a script to truncate / append data nightly from the editing to the read-only if you go down that route.

I think I have more questions than answers at this point.

[MatthewBeal]

Sorry for the delayed response. The main reason I need to maintain a separate editing environment is due to the way attribute rules have been implemented. Previously, we used arcmap and attribute assistant to automate some of the attribute entry for our features. I am trying to switch my department completely away from ArcMap. 

Attribute rules are not backwards compatible with ArcMap, however. So to get around this, I want to create our own branch where the attribute rules are applied that only we access and then automate the process of updating the version of data that everyone else is viewing in ArcMap since I can't mandate that they make the switch to ArcGIS Pro. 

I'm not opposed to getting away from the LGIM model. if there is a compelling reason to do so. It's just what we have at this point and it does the job. 

[George_Thompson]

Thanks for the clarification and thoughts. I can see where you may need the separate EGDB for the Pro based users. I would think that this would create a lot of headache for admin / maintenance tasks.

Would it be possible to have a separate FC(s) that are in the same EGDB and only visible to certain teams via permissions?

Those FC(s) could then have the attribute rules attached and used by the Pro users.

I am not an expert in attribute rules, so others may have other thoughts / experiences.

[MatthewBeal]

Yeah, it would be possible. I just liked the idea of having an editing and production environment separate from each other. So is replication not practical for this? I can write scripts for automating most of the admin tasks if necessary. Just trying to figure out if replication is a feasible solution.