We have a situation exactly like that shown in the documentation for creating a peer-to-peer merge replication. That is, we have three servers, one each in Chicago, New York, and Bermuda. Users in each office will read and write to their respective servers and the servers will then replicate with one another. The documentation, however, only shows how to set up peer-to-peer for a transactional replication. The problem is that the various Manger Studio options and the database stored procedures are NOT the same between transactional and merge replication and on the face of it, merged replication does not support a peer-to-peer topology. Can somebody walk me through the process of creating a peer-to-peer merge replication, or else convince me that I should go with transaction with updating subscriptions -- in contravention of what the documentation seems to reccommend? I'd really appreciate it!
Thanks.
Randy
before any recommendations, what are your business requirements in terms of latency? regarding a merge replication, is there something else you require that prohibits you from doing a standard publication with two subscriptions?|||In terms of business requirements the only issue is that three distinct set of users, in three different parts of the world, are updaing their own local servers but that update information needs to be reflected on all servers. The way my boss and I read the documentation, the two options are merge or transaction with updatable subscriptions. Between the two options, the documentation seems to encourage peer-to-peer merge replication.
As for latency, we're probably talking less than 50 transactions per second. Indeed, I suspect we are more in the 10 to 20 range. Since we have big pipes and good servers, I don't expect latency to be much of a problem no matter what we do.
Thanks for your input.
Randy
