I am trying to set up replication for the following scenario. Four satellite offices send changes daily up to a master database. Then, at the end of the day, the master database, which incorporates all the updates from the offices, sends an updated copy of the db back to the 4 offices; at the beginning of the next day, each office now has an updated db to work with.
Merge replication worked to a point; I was able to have 2 of the 4 offices merge data up to the master db. So far, so good.
But I cannot get the master db to replicate back down to the satellite offices.
I have seen mention of updatable subscriptions. Is merge by definition supposed to be updatable? And does this mean that all changes at the subscriber are supposed to come back to the publisher?
Thanks in advance for any insight into this.
When you sync (default is upload and download), any changes at the subscriber are uploaded to the Publisher and any changes made at the Publisher are downloaded to the Subscriber. (Note that you may have to handle or plan for conflicts on DML at publisher and subscriber or other subscribers).
That being the case, when you synched after making subscriber changes, data at publisher and the subscriber is in sync.
So when you say:
"But I cannot get the master db to replicate back down to the satellite offices"
what do you mean?
1. Are your changes made at publisher not going down to one subscriber or all subscribers or some subscribers?
2. Were you looking for reinitializing the subscriber?
3. Do you have filters in articles that can prohibit changes from one subscriber not making it to another subscriber?
By default, changes can be made at both the merge publisher and subscriber.
Please describe more clearly your problem as it will help in troubleshooting.
|||Merge is the right publication type for what you want to do. By default, merge subscriptions are updateable and the changes to the replicated data will be synchronized with the Publisher. (The term "updatable subscription" usually refers to a feature of transactional publications that allow immediate updating or queued updating subscriptions.)In this scenario, you will have to do two merges for each subscription to complete the round-trip synchronization:
1) Each subscription synchronizes with the Publisher.
2) After the Publisher has all data from all Subscribers, synchronize again so that the data can be sent to the Subscribers.
Is your publication filtered? If you are using dynamic filtering in your publication such that the different subscriptions receive different partitions of the data, a subscription will never receive data that doesn't fit in its partition. When you synchronize in step 2 above, changed data at the Publisher would never get send to the other subscriptions.
Phil Garding
No comments:
Post a Comment