Is child replicated data able to be edited?

[NickAlexandrou1]

I am trying to think of way to keep our data organized while enabling users to make field edits. If I have an SDE database that is where my analysts make edits and manage our data (DB - A), can I make a one-way replication of a specific dataset that is updated weekly to another SDE database (DB - B), which can then be edited by users? My question is, if the data that end users need to be editing is created and updated via a replication process from another DB, are end users still able to make field edits to the replicated data or are the database functions that prohibit this from being enabled?

[JoeBorgione]

You can make edits to any feature class in any geodatabase that you have read/write access to.  The field edits will stay until/unless the parent features are changed and synced.  This can be a good thing and a not so good thing at the same time.

Good thing example:  I maintain an SDE database where all edits are done, and replicate one way to a file geodatabse.  One of the feature classes I replicate is street centerlines.  I point several geocoding locators to child fgdb including a 'freeways' and a 'centerlines'.  When I initially created the centerlines replica, I deleted out all the freeways from the child fgdb for two reasons:

1. Freeways don't change as much or as often (if ever) as do surface streets

2. If I left the freeways in the centerlines, it goofs on my geocoding results

Not so good thing example: see above...  I needed to project/export centerline data out for another application, so I used my child feature class.  Once that was done, I gasped and said to myself:  what the **** happened to my freeways....

[NickAlexandrou1]

So if users are making field edits to server based feature services in AGOL, it will update the child replica data they are referencing, however, whenever I run a new sync, all changes made and all data will convert to whatever state the Parent data is in when sending? That's kinda of a bummer if users are making edits for ongoing projects. Hmmmm.... I gotta ponder this for a bit. Thanks for your response!

[JoeBorgione]

I'm not a AGOL guy, but lets say your field guy makes and edit to feature 1 of feature class A.  Field guy has that edit as long as feature 1 in feature class A is not edited in the parent  sde.  If it is edited in the parent, and the parent is synced to child ( in your case to your AGOL database) the parent and the child are 'in sync' (not the boy band).  That's what a two-way replica is for but both parent and child need to some flavor of sde database.  As the administrator, you can control the direction of the synchronization process: child to parent or parent to child or both ways. 

In my scenario, I have several agencies that have their own SDE databases so they have a two way replica set up. Let's say cities A,B & C all have their own SDE while cities D,E, F do not.  A,B, & C make edits to their local SDE database features while D,E,&F use a connection to my parent SDE to make their edits. Once A,B,& C perform a two way sync, they 'push' their local SDE edits to my SDE and at the same time 'pull' any edits that D,E & F have made to the parent.  The trick is having an m-o-u in place that states City A doesn't mess with City D's data and vice-versa.