Monday, February 20, 2012

Merge replication and long disconnections

We have a system that uses SQL2000 (SP2) with the main database in our main
location. We have been working on setting up replication to a secondary
location, and believe we have solved the relevant issues there. We have
just been asked (read told) to set up replication to another server that
will, by it's nature, be disconnected for extended periods of time (at least
weeks) with no possibility of getting an internet connection during that
time. Can we setup merge replication in this situation, what are the
"gotchas" that we need to design around? We must use merge replication
since some of our fields are text fields.
We are initially looking at setting up the client to be disconnected as a
pull subscription, while the secondary client is a push subscription from
the publisher at the main location. Does this make sense?
All input appreciated.
TIA
Ron L.
Ron,
the most striking thing to get right is @.retention. By default it'll be 14
days which isn't long enough in your case.
Push or Pull is your choice depending on who you want to be in control. If
you know when the remote client will be connected on a regular basis, then
push is still an option, but in your scenario I agree that pull seems more
reasonable.
Regards,
Paul Ibison
|||Paul
Thanks for the pointer. I'll take a look for @.retention.
Ron L.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:ecYZkfaFEHA.712@.tk2msftngp13.phx.gbl...
> Ron,
> the most striking thing to get right is @.retention. By default it'll be 14
> days which isn't long enough in your case.
> Push or Pull is your choice depending on who you want to be in control. If
> you know when the remote client will be connected on a regular basis, then
> push is still an option, but in your scenario I agree that pull seems more
> reasonable.
> Regards,
> Paul Ibison
>

No comments:

Post a Comment