Replication-Feature dataset-SDE

[AnnCrystal]

Hi All:
Is there any way that I can replicate a Feature Class stored in a Feature Dataset in Maintenance DB to a Featureclass (without Feature Dataset) in Production DB?
When I was trying to create replica, I could only create the FC from the Feature Dataset to Feature dataset. I just want to store the replica FC outside of any Feature Dataset in Production DB.
Any thoughts?
Thanks

[JonDeRose]

anncrystal -

You could create a replica using the register with existing data option.  You would first copy the data over to the child geodatabase outside of the feature dataset after the addition of GlobalIDs and then create the replica from parent to child.


Replicas created with the option to register with existing data

- Jon

[AnnCrystal]

Thanks Jon. The FC in the Feature dataset is a Topology FC. So, when I was trying to create Replica with a "Register with existing data" option and unselecting all other related FC and Topolgy schemas in Full Model mode, it fails. If I do the same with a Simple Mode, ArcMap crashes. Could you suggest an ideal workflow for this replication? I don't think I have to keep the topology in the Production database.
Any thoughts?
Thanks
Ann

[JonDeRose · Accepted solution]

anncrystal -

OK, so i tested my earlier suggestion including the topology and also see the same issues.  While that should work in theory you have to get tricky with how you copy data around.  Without the topology this does work.

An easier option which I have also tested that DOES work is as follows:

1) Create a one-way replica using the SIMPLE model with all defaults.  This  will exclude the Topology.
2) On the child geodatabase drag the feature classes outside of the Feature Dataset
3) Delete the Feature Dataset.  You will get warnings stating that this Feature Dataset belongs to a replica...continue with deletion.

As this is a one way replica there should be no issues yet please note that this is not a usual or documented workflow so please test this extensively before putting something like this into Production. 

- Jon

[AnnCrystal]

Thanks Jon. That worked like a charm.
However, I am confused while reading the documentation on Replication and Topology:
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/Replication_and_topology/0027000000290...
ESRI mentions not to separate individual FC from the replica. When running in simple model-topology is excluded and that I am replicating only one FC from the set of topology FC.

Why is ESRI recommending of replicating all the FC as a group when we can do simple model option without bothering about topology? And, nobody intends to edit the Production FC?

Any thoughts?
Thanks for your help.
Ann

[AllanBenvin]

We are also trying to replicate from an edit GDB containing layers in various feature datasets to a published GDB with a different structure (different feature datasets).

The only way we create a replica in this scenario is to:
1) Create/paste the layer to the published GDB. Must be outside of a a feature dataset.
2) Create a dummy feature dataset in the target named after the source FDS.
3) If there is a relationship class in the source to any other FDS, then create dummy FDS's for those in the target.
4) Create the replica.
5) delete the dummy feature datasets
6) move the target layer into the desired feature dataset.

You may be thinking what a huge pain in the a$$. Yes. Yes it is. The problem is even worse in a production system. We can't be moving layers outside of feature datasets and creating dummy feature datasets without an outage of service to the users. The point of the published GDB is to have the highly available data for internal and external map services. The way locking works on feature datasets everything is pretty much guaranteed to be locked all the time. Why should we have to create dummy FDS just to create a replica?

[AsrujitSengupta]

The point of using the "Register with existing data" options is that the data present in both the geodatabases should be exactly similar. Only then is this option viable.
This is the reason we need to create dummy DTs with the same name as the existing DTs, just to create the replica between the two.

If you want to avoid creating dummy DTs, simply use the create replica tool, which will automatically create similar DTs in the target geodatabase.

[HeatherMcCracken]

The point of using the "Register with existing data" options is that the data present in both the geodatabases should be exactly similar. Only then is this option viable.
This is the reason we need to create dummy DTs with the same name as the existing DTs, just to create the replica between the two.

Just want to clarify - you DO NOT need to create the dummy FD in the target.  Replication doesn't look at this level - it's only looking for the table itself (whether or not it's in a FD is not important).  If you have the FC outside of the FD on the target, it will still recognize this as being the same table.  Fields names need to be the same in order to be synced, however you can have fields on one side that are not on the other.  Replication will just sync fields that match - if it can't find the field on the other side, it will just be ignored on sync.

What is very important to ensure when doing the "Register existing data only" option, is that the GlobalID values of each feature are the same between the geodatabases.  This is how replication maintains object identity between the databases.  For example - copy past preserves the GlobalID value, as does the create replica operation (among others). 
Where as if you independently added globalIDs to either gdb separately (i.e Rclick > Add GlobalID on the source GDB data, and then independently Rclick > AddGlobalID to the target) the GlobalID's for you features woulc be different, and therefore changes would not get synced.

Hope this helps.
Please let me know if you have any follow on questions on my statements above.
-Heather

[C_EHoward]

I was not able to create a replica with the 'register existing data only' option when my data in the parent SDE were in a FD and the child file GDB has the same datasets as feature classes in the GDB. The FCs in the child are copied from the SDE so the global IDs are the same. Unless I am reading this explanation incorrectly, there still needs to be a FD for which the replica toolbar (ArcMap) looks for when replicating-- if not, there are no datasets listed on the dialog, even though they are in the GDB already (just not in a FD as in the parent SDE)

I verified the work around about moving the data out of a FD in the child after replication, but that seems contrary to the above post. Different staff recommending/saying different things is nothing new, but if it is possible to one way replicate with data from FD to FCs I would love to know how to do it--- and to have this all explained in the documentation somewhere (but wont hold my breath! )

[C_EHoward]

There is a bug associated with this -

Bug NIM-061898

that has apparently been on the books since 2010! According to the analyst I am working with, it is supposed to be addressed in the next release, but considering its been over 5 years and a new release just happened, I am skeptical.