Here is the scenario, 2 SDE databases and 1 File GDB. We want the parent SDE to replicate to the child file gdb. Then the other SDE database copies the data from the file gdb to their SDE. Then the second SDE would become the parent and the file gdb would still be the child. We would then like to be able to send changes from the child file gdb to the second parent SDE(Child to Parent)
1. SDE1(Parent) replicates to a file gdb(child)
2. Copy data from file gdb(child) to SDE2(Parent)
3. Register with existing data (SDE2) to file gdb(child) with 1 way replication (Child to Parent)
This prevents users from having to expose data owner connections which is currently a limitation of the register with existing data option. For large datasets and situations where admins do not want to expose data owner connections this would be ideal. There are other workarounds but I thought for environments where there are issues with domains and connectivity between SDE's this would be a helpful workflow.
Since the file gdb is an Esri proprietary format, I figured some reverse engineering could be done to account for versioning in a file gdb. Since replication relies heavily on versioning I would imagine some workflow could be built into the file gdb behind the scenes to make this possible. It also allows the data owners and various SDE's involved to manage their own replicas and still be able to achieve a full compress. If people create replicas off of your SDE without your knowledge and they do not keep the syncs consistent it makes it nearly impossible to achieve a full compress without unregistering those replicas which you do not manage yourself. This would offer a solution to that problem because you being the SDE admin could manage the push to the file gdb and others could pick it up from the file gdb versus creating replicas in your SDE without your knowledge.
