Hi there,
In a lot of the Replication documentation it only refers to the merge agent operating in the context of a push or a pull configuration. i.e. if it is push then the merge agent is at the distributor but if it is a pull then the merge agent functions at the subscriber.
I recently joined a project which is configured as a push but it uses RMO for synchronisation. This RMO application is installed on a compeletely separate server. Initially I thought the RMO was just passing requests through to the publisher/distributor/subscriber but the distributor didn't seem to be doing any of the work. It therefore seems that the merging/synchronisation is being performed on this RMO application server and not the distributor or subscriber.
I therefore think it would be good (assuming I am correct of course) that the documentation reflects this caveat
As a general observation Replication programming seems to be quite detached from the rest of the replication documentation. Is this a deliberate decision?
It isn't normally, but I'll ping the writer in charge of this and ask.
Buck Woody
|||
To answer your last question first. Yes, it was a product-wide design decision to put all of the programming API documentation for SQL Server together in a separate node. I agree with you that it isn't ideal. In the next release of SQL Server, we will include the programming content for each component with the rest of the component's conceptual content.
There is no general requirement that an RMO application run on a replication server. SQL Server Management Studio (SSMS) uses RMO to perform administrative tasks in replication, and you can administer replication on remote servers using SSMS. You can also synchronize subscriptions remotely using RMO (MergeSubscription.SynchronizeWithJob in the case of a push subscription), which runs the agent job on the Distributor to asynchronously start the Merge Agent. To run the Merge Agent synchronously (MergeSynchronizationAgent.Synchronize) and receive callbacks (synchronization status events), your application needs to run on the same server as the Merge Agent (the Distributor in your case).
I will see if we can make the RMO documentation more clear on this point.
Best wishes,
Glenn Gailey [MSFT]
SQL Server UE
|||Hi Glenn & Buck,
Thanks very much for getting back to me.
I am glad to hear that the API docs will be more integrated in katmai.
On the other point I am a little confused. In our setup the merge application using RMO runs on a totally separate server to the distributor but this third machine (distributor is remote to the publisher) has SQL Express installed. We get back all the callbacks and replication is operating. I mention this because I think this kind of setup isn't really referred to in BOL but I also believe it is a permissable setup (although not perhaps a very common one).
Cheers, James
|||Is your RMO application running on the Subscriber server, or on a 4th server totally outside the Pub/Dist/Sub topology?|||It sits on a completely separate 4th server.
Cheers, James
|||I checked with the development team, and it is possible to run the Merge Agent remotely (both synchronously and asynchronously) using RMO. I will look into providing this information in the documentation.
Cheers!
|||Is it possible to run application that uses RMO on a server without installing SQL server? From the posts in this thread I assume the 4th server has SQLServer Express 2005 installation just to be able to run RMO app.|||That is correct. You do need to have at least sql express installed. This is the only way to get the RMO components onto the server.
Cheers, James
