ELI5 (for you redditors): I have an environment where we have a single production database and two publication databases which make up our AGS Site. The two publication servers are children of the production environment with one way replication only. The minimal web based editing is done directly to the production environment.
While there are mechanisms to pass a schema change from parent to child, new feature classes have to either go into a new replication or the existing one has to be dropped and rebuilt which is annoying with a lot of tables. We keep running into situations where "register existing data", even when a feature class has been manually equalized by deleting the data in the child and appending from the parent immediately before setup, fails to register the data and changes in the parent result in problem records in the child. This happens on both publication servers with several feature classes every time the replications are recreated. Because no changes are made to the data in the publication environment its not clear why its not recommended to use SQL replication instead of esri replication.
I understand that if editing was happening in both places there could be conflicting OID created which would cause problems with network datasets, annotation, etc. which used the OID field to connect records. I know its a highly developed system but the in built geodatabase replication always seems cumbersome to deal with. Being that we have a single production database, which we are unlikely to grow out of anytime soon, we won't be in a situation where a single child is subscribed to multiple parents and we would have to deal with setting up identity ranges and such. All of our normal schema management, adding/dropping fields/tables, happens in ArcCatalog so there wouldnt be any conflict with table and field registration tables in the geodatabase.
Hi Chris,
we have a number of customers on ArcGIS 10.2.1 that use a seperate viewing database in addition totheir primary editing database. Some of them use Esri geodatabase replication, others use database mechanisms (mostly Oracle). Both methods are viable, here are some considerations from our experience:
Martin
Thanks for the reply. I would probably use transactional replication covering the entire database so we dont have any potential to break geodatabase functions accidentally. We have MSSQL for all three databases. If production wasn't ~16.5GB I would just do a snapshot every night. Right now we replicate nightly but that is a large file to move every day.