Real-time Geodatabase Replication? Part 3

730
0
01-01-2015 12:27 PM
ThomasColson
MVP Frequent Contributor
3 0 730

Setting up a Subscription Server

On your remote database server, create a NEW SDE database called "FEMPFISH" (or something other than fish).

Once the database has been created, manually replicate by right-clicking and selecting Import, and Import the TEST feature class definition from the FISH (publication) database. Make sure you select the Geography storage type. Everything about the two feature classes must be the same! If your feature class has attribute domains the best way to do this is with a XML export/import. Otherwise your feature class on the remote (subscription) server won't have attribute domain pick-lists for editors to use!

Note that I'm not using Feature Datasets here! More complexity....

On the remote SQL server activate the New Subscription Wizard.

Select the Local SQL Server that hosts the FISH database as the Publisher. You should then see this:

rftewrtwe.JPG

I prefer to run all agents at the Distributor as this a) keeps the overhead on my server that has the capacity to do so and b) makes managing many subscriptions a lot easier (one interface).

reqwr32.JPG

Select the Subscription Database as the one you created on the remote server to host the replicated feature class.

r3ew45r3.JPG

In the Agent Security, you SHOULD use the SAME domain account you used to create the Publisher Agent. Good luck with another security model....and set the agent schedule to run continuously.

r32w423.JPG

qew453.JPG

r3432.JPG

tr3254.JPG

qwer34.JPG

Real-time Geodatabase Replication? Part 1

Real-time Geodatabase Replication? Part 2

Real-time Geodatabase Replication? Part 3

Real-time Geodatabase Replication? Part 4

Real-time Geodatabase Replication? Part 5

Real-time Geodatabase Replication? Part 6

This is a personal blog and does not recommend, endorse, or support the methods described above. Alteration of data using SQL outside of the ESRI software stack, of course, is not supported and should not be applied to a production database without a thorough understanding and disaster recovery plan.

About the Author
This is a personal account and does not reflect the view or policies of my org.