The ability to add Feature Objects to a replica using ArcPy is crucial to automation. ESRI seems to push for automation, but falls short in replication. Need support not just for Feature Classes and Tables (ability to replicate data in those tables would be nice), but also Feature Datasets and those with Relationship Classes. ESRI go BIG! Go 4 The Win! Make everything related to replication available through ArcPy plus Add Feature Object to Replica. (And ability to unregister both the replica and the Feature Objects inside the replica.) I know you can do it!
Note: I'm making this comment because it is crucial to our business operations operating more smoothly thus saving time and money. It is also possible that this automation could save our data integrity due to the current process requiring too many manual steps that could introduce error.
I agree with Mateo. Adding a removing feature classes from a replica without the having to program it in ArcObjects is needed. I have 3 feature classes out of 40 in a replica that got corrupted so it would be nice to remove them from the replica, replace originals and replicate got those feature classes without blowing away the replicas.
Just wanted to bump this up since this was requested in 2010 and 10 years later this is still not available as far as I can find. I know this can be done using ArcObjects, so it is not impossible, but it should be exposed through the UI and python. Maybe my organization is unique but we often have to create new feature classes over time.
My first thought was, maybe they don't think it's necessary because you could script the re-creation of replicas via Python...then I found that there is no ArcPy method to unregister replicas. It doesn't make sense that you can create a replica via ArcToolbox and therefore ArcPy...but you cannot unregister them.
I had replicas going for years on end, and they are very reliable as a way to automate the updating of a read-only file geodatabase copy of an enterprise geodatabase. They stopped propagating edits reliably just recently and there was no way to fix the problem besides unregistering the replicas, deleting the child data, and re-creating the replica. I could have fired off a fix-it script in minutes, and not waited 2 weeks for Esri to tell me they can't figure out what went wrong.
We are getting ready to migrate our GIS data to a new server and I am tempted to just write a python script that is scheduled to disable connections to the read-only enterprise geodatabase, wipe it, and recopy everything. That way I do not have to worry about adding new feature classes, schema changes, or failed/incomplete edit syncs (that has happened more than once and forced me to recreate the entire sync setup anyway). However, I do not like that it is not efficient since most of the data will not have any changes.
I have also found myself wondering as of late, what even is the advantage of using replicas in a read-only scenario? Without consulting Esri, the only thing I could come up with is that the update process is a simple, one-tool job. I wonder if the back-end complexity and associated failure risk is worth it? In our case of writing out to a read-only file geodatabase, it would be simple enough to delete and recreate feature classes with a python script. Or in the case of an enterprise geodatabase, delete features and re-load. At the time, I suppose I opted for the solution that was easy to implement. That is is, for sure.
I'm doing server moves as well, so I'm right there with you.
You must have another reason for using a enterprise geodatabase in a read-only capacity. The whole idea of the enterprise geodatabase is primarily multi-user editing.
Originally we used an enterprise geodatabase as our read-only database because we still needed to control who had access to which feature classes in the geodatabase.
