views:

455

answers:

1

I have a CRUD winform App that uses Merge Replication to allow "disconnected" functionality. My question is; If I am doing all initializing and synchronizing programatically with RMO (like HERE) does it matter if it is a Push or Pull?

What would be a difference?

I understand the differences between the two (see HERE) but it seems that if I am only interacting through RMO the differences become a little fuzzy. If I can it seems that, even though Pull is favored for Merge Replication, I would want to use Push to make the Server bear the brunt and easier management.

Also, due to our environment, I do not need "real-time" updates. Syncing, in either case, will be fired from a UI event.

Does anyone have any experience with this?

Thanks!

+1  A: 

We use merge replication via RMO on 20+ client systems that are occasionally connected. As far as I know, you should go with pull subscriptions. I don't know if you could make it work with push subscriptions but I don't advise trying. As you say, the client system will be requesting the sync, which fits the definition of a pull subscription.

The "Use When" section in your second link is pretty clear in its recommendation for push in this case:

  • Data will typically be synchronized on demand or on a schedule rather than continuously.
  • The publication has a large number of Subscribers, and/or it would be too resource-intensive to run all the agents at the Distributor.
  • Subscribers are autonomous, disconnected, and/or mobile. Subscribers will determine when they will connect and synchronize changes.
  • Most often used with merge replication.
Jamie Ide