Come aggiornare il risolutore di conflitti durante l'aggiornamento da SQL Server 2005 a SQL Server 2008

Question

Abbiamo recentemente eseguito l'aggiornamento da SQL Server 2005 a SQL Server 2008 (R2, SP1). Questo aggiornamento includeva alcune pubblicazioni, in cui tutte le tabelle sono pubblicate con un risolutore di conflitti predefinito basato sul principio "successi successivi". Il suo nome intelligente è "Microsoft SQL Server DATETIME (Successioni successive) Risolutore dei conflitti" e il file dll corrispondente è ssrmax.dll.

Come tutti sapete, una volta pubblicata una tabella con un risolutore di conflitti, lo stesso risolutore di conflitti deve essere utilizzato in tutte le pubblicazioni successive che utilizzano questa tabella. Va bene, ma, quando si aggiungono le tabelle pubblicate in precedenza alle nuove pubblicazioni, e specificando la stessa risoluzione dei conflitti da utilizzare per questa tabella, stiamo ottenendo un messaggio di errore:

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 

e questo è l'errore si ottiene:

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

cercando di capire come la stessa risoluzione dei conflitti non è considerata dalla macchina come 'la stessa risoluzione dei conflitti', ho scoperto che c'erano due resolver di conflitto con lo stesso nome, diverse versioni, nel registro di sistema:

th E 2005 Versione:

• file di ssrmax.dll,
• versione 2005.90.4035.0,
• cls_id D604B4B5-686B-4.304-9.613-C4F82B527B10

la versione 2008:

• file ssrmax.dll,
• versione 2009.100.2500.0,
• cls_id 77209412-47CF-49AF-A347-DCF7EE481277

e ho controllato che il nostro assistente 2008 sta prendendo in considerazione il secondo come il 'risolutore personalizzato disponibile' (ho ottenuto questo eseguendo sp_enumcustomresolvers). Il problema è che entrambi i riferimenti sono disponibili nel registro, quindi suppongo che le vecchie pubblicazioni facciano riferimento alla versione del 2005, mentre le nuove pubblicazioni cercano di fare riferimento alla versione 2008, che è in effetti diversa da quella precedente.

Quindi la domanda è: come posso fare in modo che il server consideri solo una di queste 2 versioni, e questo (ovviamente) senza dover abbandonare e ricreare le pubblicazioni esistenti (che trasformerebbero la nostra vita in inferno per i prossimi 2 settimane).

Answer 1

Bene .. quindi nessuno ha ottenuto una risposta. Ma penso di aver (finalmente) capito. Indovina che ... è da qualche parte nel metamodello (come al solito)!

• Quando si aggiunge un elemento alla sottoscrizione, i nuovi riferimenti del resolver di conflitto da utilizzare dalla procedura memorizzata provengono dalla [distribuzione].[MSmerge_articleresolver] tavolo
• Ma, per gli abbonamenti esistenti, di conflitto precedente riferimenti resolver vengono memorizzati nelle tabelle di sistema del database di pubblicazione, vale a dire [sysmergearticles], [sysmergeextendedarticlesview], e [sysmergepartitioninfoview]

Così abbiamo da un lato un articolo pubblicato inizialmente con SQLSERVER 2005, in cui la pubblicazione fa riferimento al resolver del conflitto del 2005, come da metamodel del database di pubblicazione. Dall'altro lato, la macchina tenterà di aggiungere lo stesso articolo a una nuova pubblicazione, questa volta con un riferimento predefinito al risolutore di conflitti disponibile nel database di distibuzione, che è effettivamente diverso da quello del 2005. ....

Per illustrare questo, è possibile controllare il seguente

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

Poi,

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 

Così sembra che devo aggiornare sia i riferimenti nel database di distribuzione o dei riferimenti nel database di pubblicazione. Proviamolo!

Answer 2

Grazie, aveva qualcosa di simile su un re-editore in cui l'articolo sottoscrittore aveva un CLSID che non aveva senso sul server (guardato con Regedit) ma quando si cercava di aggiungere l'articolo ad una pubblicazione avrebbe prodotto detto errore.

Aggiornato il campo resolver_clsid del tavolo sysmergearticles per l'articolo sottoscritto con la clisd che stava cercando di ottenere

{ 

declare @resolver_clsid nvarchar(50) 

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


select @resolver_clsid 

} 

e potrebbe quindi aggiungere l'articolo