Cómo actualizar la resolución de conflictos al actualizar de SQL-Server 2005 a SQL-Server 2008

Question

Recientemente hemos actualizado de SQL Server 2005 a SQL Server 2008 (R2, SP1). Esta actualización incluyó algunas publicaciones, donde todas las tablas se publican con una resolución de conflictos predeterminada basada en el principio de "victorias posteriores". Su nombre inteligente es 'Microsoft SQL Server DATETIME (más tarde gana) Conflict Resolver', y el archivo dll correspondiente es ssrmax.dll.

Como todos saben, una vez que se publica una tabla con una resolución de conflictos, se debe usar la misma resolución de conflictos en todas las publicaciones posteriores que utilicen esta tabla. Justo lo suficiente, pero, al agregar tablas publicadas con anterioridad a nuevas publicaciones, y especificando la misma resolución de conflictos que se utilizará para esta tabla, estamos recibiendo un mensaje de error:

use [myDb] 
exec sp_addmergearticle 
    @publication = N'myDb_Pub', 
    @article = N'Tbl_blablabla', 
    @source_owner = N'dbo', 
    @source_object = N'Tbl_blablabla', 
    @type = N'table', 
    @description = N'', 
    @creation_script = N'', 
    @pre_creation_cmd = N'drop', 
    @schema_option = 0x000000000C034FD1, 
    @identityrangemanagementoption = N'none', 
    @destination_owner = N'dbo', 
    @force_reinit_subscription = 1, 
    @column_tracking = N'false', 
    @article_resolver = N'Microsoft SQL Server DATETIME (Later Wins) Conflict Resolver', 
    @subset_filterclause = N'', 
    @resolver_info = N'ddmaj', 
    @vertical_partition = N'false', 
    @verify_resolver_signature = 0, 
    @allow_interactive_resolver = N'false', 
    @fast_multicol_updateproc = N'true', 
    @check_permissions = 0, 
    @subscriber_upload_options = 0, 
    @delete_tracking = N'true', 
    @compensate_for_errors = N'false', 
    @stream_blob_columns = N'false', 
    @partition_options = 0 
GO 

Y este es el error que obtenemos:

The article '...' already exists in another publication with a different article resolver. 

al tratar de comprender cómo la misma resolución de conflictos no es considerado por la máquina como 'la misma resolución de conflictos', descubrí que había dos resoluciones de conflictos con el mismo nombre, diferentes versiones, en el registro:

th e versión 2005:

• archivo ssrmax.dll,
• versión 2005.90.4035.0,
• cls_id D604B4B5-686B-4304-9613-C4F82B527B10

la versión 2008:

• archivo ssrmax.dll,
• versión 2009.100.2500.0,
• cls_id 77209412-47CF-49AF-A347-DCF7EE481277

y yo nos registramos que nuestro servidor 2008 está considerando la segunda como la 'resolución personalizada disponible' (Tengo esto ejecutando sp_enumcustomresolvers). El problema es que ambas referencias están disponibles en el registro, así que supongo que las publicaciones antiguas se refieren a la versión de 2005, mientras que las nuevas publicaciones intentan referirse a la versión de 2008, que es realmente diferente de la anterior.

Entonces la pregunta es: ¿cómo puedo hacer que el servidor considere solo una de estas 2 versiones, y esto (por supuesto) sin tener que soltar y recrear las publicaciones existentes (que convertirían nuestra vida en infierno para los próximos 2 semanas).

Answer 1

Bueno ... entonces nadie recibió una respuesta. Pero creo que (finalmente) lo tengo. Adivina qué ... está en algún lugar del metamodelo (como de costumbre)!

• Al agregar un elemento a la suscripción, las nuevas referencias de resolución de conflictos que se utilizarán en el procedimiento almacenado provienen de [distribución].[MSmerge_articleresolver] mesa
• Pero, para las suscripciones existentes, las referencias solucionador de conflictos anterior se almacenan en las tablas del sistema de la base de datos de publicación, es decir, [sysmergearticles], [sysmergeextendedarticlesview] y [sysmergepartitioninfoview]

Así que tenemos por un lado, un elemento publicado inicialmente con SQLSERVER 2005, donde la publicación hace referencia a la resolución de conflictos de 2005, según el metamodelo de la base de datos de publicación. Por otro lado, la máquina intentará agregar el mismo artículo a una nueva publicación, esta vez con una referencia predeterminada a la resolución de conflictos disponible en la base de datos de distribución, que es diferente de la de 2005 ....

Para ilustrar esto, se puede comprobar lo siguiente

USE distribution 
go 
SELECT article_resolver, resolver_clsid 
    FROM [MSmerge_articleresolver] WHERE article_resolver like '%Later Wins%' 
    GO 

Entonces,

USE myPublicationDatabase 
go 
SELECT article_resolver, resolver_clsid 
    FROM [sysmergearticles] WHERE article_resolver like '%Later Wins%' 
    GO 
SELECT article_resolver, resolver_clsid 
    FROM [sysmergeextendedarticlesview] WHERE article_resolver like '%Later Wins%' 
    GO 
SELECT article_resolver, resolver_clsid 
    FROM [sysmergepartitioninfoview] WHERE article_resolver like '%Later Wins%' 
    GO 

por lo que parece que debería actualizar cualquiera de las referencias en la base de datos de distribución o de las referencias en la base de datos de publicación. ¡Hagamos un intento!

Answer 2

Gracias, tenía algo similar en una reedición donde el artículo del suscriptor tenía un CLSID que no tenía sentido en el servidor (buscado con Regedit) pero al intentar agregar el artículo a una publicación produciría dicho error.

Actualizado el campo de la tabla resolver_clsid sysmergearticles para el artículo suscrito con el clisd que estaba tratando de conseguir

{ 

declare @resolver_clsid nvarchar(50) 

exec sys.sp_lookupcustomresolver N'Microsoft SQL Server DATETIME (Earlier Wins) Conflict Resolver', @resolver_clsid OUTPUT 


select @resolver_clsid 

} 

y luego se podría añadir el artículo