subscriber''s records disappear with merge replication
-
Hello everyone,
I am struggling with getting a merge replication working. On the publisher, I have an empty table. The subscriber has a table of the exact same structure, with 1 record. When I engage a subscription, instead of the seeing the 1 record go up to the publisher, the subscription instead wipes out the record on the subscriber! Obviously, this is not the way merge is supposed to work, and it must be something simple I'm doing wrong. Thanks in advance for any help!
-
When synchronisation occurs b/w a Publisher and a Subscriber, the merge agent will determine which data will be propagated to where in order to achieve Data Convergence. In this instance, the Publisher's higher priority determines that the subscriber's data would have to be removed.
-
This leads to 2 questions, then:
1) If I start out with both tables empty, engage the subscription, and *then* add the record to the subscriber, the record propagates to the publisher instead of disappearing. So why does my replication work properly in this instance?
2) You mention data convergence and the publisher's priority. Is there a way to change the settings for the publisher's priority?
Thanks
-
One important thing to realise is that Merge Replication (MR) requires that both the publisher and subscriber databases are in sync. This is achieved through the application of a snap-shot file or through 'forced-replication' (search this site to found out more) if the databases contain different datasets initially.
If synchronisation starts and the two databases are different, then MR will perform a delete in the subscribing database, as in your case, to make the subscriber to be in-sync with the publisher. Once both databases are in-sync (both tables are clean), then adding records in either the subscriber or publisher will be propagated to the other. This is the two-way nature of MR.
-
In replication, i believe the data has to be in sync first before any replication can take place. Is this correct?
-
Good question! *Does* the publisher have to be in sync with the subscriber before replication can begin?
In my case, I have a publisher and subscriber who are (very) out of sync, and I was hoping to use replication to get them in sync. The publisher has some records the subscriber does not, the subscriber has some records the publisher does not, and they both have some records in common. Using merge replication, I was hoping that the subscriber's new records would go up to the publisher, the publisher's new records would come down to the subscriber, and that no records would be lost. Is this do-able with merge replication?
Thank you!
-
Ooops.....I guess I should have read your previous reply more closely. I see you do clearly say that both subscriber and publisher must be in sync before replication begins.
So that leaves the question: is there any way to use replication to get the subscriber & publisher in sync with each other--without losing any records?
Thanks again.
-
I believe that the initial snapshot is for this purpose. However I believe that the subscriber will be made the same as the publisher. This means that subscriber will become a copy of the publisher and not merge their data together. To do that, might need a third party software i think.
Aaron
Learning never stops.
-
Yes that is correct! A snapshot file is one way to create an exact copy at the subscriber for merge replication.
The approach to making exact copies of two databases would depend on whether you have existing data in one or both databases. If both databases have data, then you will have to somehow get them to be the same, which simply involves copying from one to the other. Watch out for identity columns, which may require you to set different identity ranges for each database.
-
pardon me, snapshot is not able to solve the problem where there are some data in server A and some data in server B which i like to keep. Does it? Cause i believe snapshot is bulk copy.
-
The snapshot is created based on the publishing database, and you do have the option of not applying this to the subscribing database(s) if you so desire.
As per previous emails, both databases must be exact copies, so depending on the amount of data in the databases, you may want to perform this task before replication is active, otherwise the only other option is to apply the snapshot during replication.
-
HI,
I suggest you to investigate the "@allow_partition_realignment" publication parameter.
Yu can set it via sp_addmergepublication / sp_changemergepublication
It allows/prevent data at the subscriber (which are not part of the correct partition).
True : sends deletes to the Subscriber to reflect the results of a partition change by removing data that is no longer part of the Subscriber's partition. false leaves the data from an old partition on the Subscriber, where changes made to this data on the Publisher will not replicate to this Subscriber, but changes made on the Subscriber will replicate to the Publisher.
Setting allow_partition_realignment to false is used to retain data in a subscription from an old partition when the data needs to be accessible for historical purposes.
Bye
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply