Posted by Brian Cryer on 06/24/05 18:56

If you go the replicated route then your choice (of merge, snapshot or
transactional) is probably straight forward:

- Will they ever want to make changes on the remote server? If yes then you
must use merge replication.
- Otherwise got for Transactional.

Unless the database is small don't go for snapshot. Snapshot is fine for
just that, taking the odd snapshot, but isn't really suited if you want to
regularly propagate changes.

Regarding your problem connecting to the remove server. It is quite likely
that firewalls could be causing you a problem. I've not tried it, but
presumably the most secure way forward would be to create a vpn connection
between the two servers (firewalls may still be an issue) and then replicate
across the vpn link.

Hope this helps,

Brian.

www.cryer.co.uk/brian



"debian mojo" <debian_mojo@yahoo.com> wrote in message
news:d5Sue.8$_r5.2081@news.uswest.net...
> Hello Group,
> I'm working on two SQL server databases on two different remote
> servers. What client needs is that his database on one remote server
> should be mirrored to the other one. The changed should be propogated at
> regular intervals at the other server.
>
> For now i'm quite sure that i'll have to use replication to resolve
> this issue.
>
> But which type of replication should i use? Transactional, Merge or
> Snapshot?
>
> Please note that the client is running his website from the main
> server, which is using the source SQL Server database - the one i'll
> have to replicate.
>
> Last time when i tried to register the destination server, at my
> source server Enterprise Manager, it gave me an error failing to
> register the destination server. When i asked the client, all he could
> tell me was that both the servers are firewalled and that might have
> been the problem.
>
> So just tell me how should i go for it?
>
> Thanks in advance
> Debian
>
>
>
> *** Sent via Developersdex http://www.developersdex.com ***

[Back to original message]