I have so far renamed the top tier's instance, reconfigured publication, created a new top tier publication, and a new middle tier subscription. The top tier article has been set to delete all data in the subscriber's table when applying the snapshot. Making data changes at the middle tier filters correctly to both the top and bottom tiers. However, any changes made at the top or bottom tiers filter to the middle tier but no further. At that point, there are no errors, but simply no data needing to be merged.
Does anyone know how dropping and recreating a top tier publication could cause a 3 tiered replication architecture to behave like this? Is there any solution short of having to recreate subscriptions on all the bottom tier laptops?
check if there is some data to be merged in MS_mergecontents , and evn MSmerge_tombstone , if u find data in there , it shud merge..do a manual syncronize at the subscriber, if it dosent work , try reinitializing the subscription if thats feasible..|||so, I recreate the top tier publication and subscription, create a snapshot, synchronize the middle tier, create a middle tier snapshot, synchronize the bottom tier. At that point, I add a row to a replicated table on the top tier, synchronize the middle tier, and synchronize the bottom tier. As I stated, the data never makes it past the middle tier. The row guid appears in msmerge_contents and msmerge_genhistory on both the top and middle tiers. The bottom tier, however, never receives the data. Any ideas where I can go from here?|||
Can you verify the the subscriber in the middle tier is a "global" subscriber?
select * from sysmergesubscriptions, and look at the value in column subscriber_type, check if it has value of 1.
|||the subscriber_type is 1 for the middle tier subscription to the top tier publication.|||Additionally, the middle tier subscriber passes data validation, whereas the bottom tier subscriber fails data validation.sql
No comments:
Post a Comment