Hello,
This is my first time on the Social Forums, so I hope I manage to explain myself.
This is our scenario (it’s a bit complex).
Initially we had a SQL Server 2005 SP3 CU4 instance as publisher in a Merge replication topology with several pull subscribers.
On this server we decided to perform an upgrade to SQL Server 2008 R2 CU7 (from now on 'Inst1').
We had set a Custom Conflict Resolver ('Microsoft SQLServer Stored Procedure resolved') for one article in a bidirectional merge publication that continued to work correctly after the upgrade was finished.
So far, so good. Now we needed to scale up our solution by adding a second merge publisher to our topology ('Inst2'). Since both merge publishers must be kept in sync, we set Peer-to-Peer replication between them to achieve this synchronization (each publisher
is a node within a cluster).
After setting up on the second server and instance with both databases correctly in sync (both are identical), we have all merge-subscribers replicating against 'Inst1' and 'Inst2' is being properly updated by Peer-to-Peer replication. At this point we
created merge-publications on 'Inst2' identical to those already existing on Inst1 and everything seemed to work just fine.
Now we wanted to move one merge-subscriber from Inst1 to 'Inst2'. In order to do this we removed its subscriptions to Inst1, created new subscriptions to 'Inst2' and started the initial merge-replication against 'Inst2'.
And here is where the problem begins. During this initial merge-replication of the subscriber against 'Inst2' an error is generated related to the Custom Conflict Resolver:
"The process could not initialize 'Microsoft SQLServer Stored Procedure resolved'." Verify that the component is registered correctly."
So far the only difference between both merge-publishers that we have found is the schema_option specified for the article (sysmergearticles) that uses the custom conflict resolver (based on a stored procedure):
Inst1: Schema_Option = 0x000000000C034FD1 Resolver_Clsid = {87EC4491-1B75-4844-B7CF-090A1FB84BA6}
Inst2: Schema_Option = 0x000000B20C034FD1 Resolver_Clsid = {D264B5C0-1300-471A-80C9-9C1FC34A3691}
If we set this article conflict resolution to its default option (publisher wins all conflicts), merge replication works like a charm. But if we set it again to use the custom resolver, we get the same error message again.
Now just another curiosity. Trying to further investigate this problem, we tried and changed on 'Inst1' the article properties to use the Default Resolver (obviously this does not produce any error). And then we changed it back to use the 'Microsoft SQLServer
Stored Procedure resolved' option. Surprisingly with this setup we get on Inst1 the same error message as on 'Inst2' (always during merge replication).
Under these circumstances we checked again the sysmergearticles table on both instances and obtained this:
Inst1: Schema_Option = 0x000000000C034FD1 Resolver_Clsid = {D264B5C0-1300-471A-80C9-9C1FC34A3691}
Inst2: Schema_Option = 0x000000B20C034FD1 Resolver_Clsid = {D264B5C0-1300-471A-80C9-9C1FC34A3691}
This is, now we have the same Resolver_Clsid on both publishers and merge replication doesn’t work against any of them.
So, after this long explanation, probably everything comes to one question?
Are there any known limitations to conflict resolution with merge replication when the publisher is at the same time involved in peer-to-peer replication?
Any help would be appreciated.
Thanks in advance and best regards.
Fran Lens http://es.linkedin.com/in/franlens