SS2005 Merge Replication through message queue

[balabaster]

I have an odd scenario whereby I have two SQL 2005 Servers separated by a firewall and the only means of them talking is via a 3rd party message queueing server. I have a database on each of the SQL servers that needs to be replicated in both directions...th is network architecture is not of my doing and security dictates that this cannot change.

In my test environment I've just started investigating how exactly I'm going to approach this and have got as far as setting up multiple instances of SQL 2005 Server and setting up merge replication to successfully keep the two databases synchronized.

At this point, I'm stuck...it seems to me the manner in which merge replication works, I'm not going to be able to use this mechanism to replicate through the message queue, I'm wondering if anyone can give me any relevant input.

Thanks in advance

[balabaster]

No takers? I guess I should clarify my question. In the event that my two SQL Servers cannot talk to each other directly, how do I go about achieving synchronicity between my two databases? Can replication be made to work in a disconnected fashion? Or should I be considering alternative solutions?

[ck9663]

Can you try installing a third-party solution on a third machine that can access both? If they can not access each other directly, can you setup a third machine and run everything from there? Like:

If ServerA <----> ServerB is not possible, try:

ServerA <---- ServerC ---> ServerB

(Those arrows represents connections)

-- CK

[balabaster]

Can you try installing a third-party solution on a third machine that can access both? If they can not access each other directly, can you setup a third machine and run everything from there? Like:

If ServerA <----> ServerB is not possible, try:

ServerA <---- ServerC ---> ServerB

(Those arrows represents connections)

-- CK

Sadly the network is set up in such a way that the only communication between the two subnets is through a messaging queue which is the only hole through the firewall. There's no possibility of setting up machines in a manner that can bypass this. Corporate security guidelines dictate that any and all communication between the two subnets goes through the message queue. I was wondering if there was any way to transmit the transaction log through the message queue and integrate changes on both sides and thus keep the databases synchronized this way.

[ck9663]

I'm not sure if the logs would be sufficient enough to do it. How about a third-party application like an ETL? Sounds to me that even if your environment is the same (same sql server) you might end up doing (as if) an integration.

-- CK

[balabaster]

I'm not sure if the logs would be sufficient enough to do it. How about a third-party application like an ETL? Sounds to me that even if your environment is the same (same sql server) you might end up doing (as if) an integration.

-- CK

Okay, it looks like I'm going to have to write some custom mechanism to do this which will sync data in a handful of the tables - that is, those tables which are likely to change on a daily basis as the application is maintained. Other tables will have to be maintained manually. I was hoping that the mechanism would allow for a more organic evolution of the database such that any and all changes would be synched but it seems that the security constraints of the network topology prevent such a solution from being put in place.