6

Niedawno zaktualizowaliśmy program SQL Server 2005 do wersji SQL Server 2008 (R2, SP1). Ta aktualizacja obejmowała kilka publikacji, w których wszystkie tabele są publikowane z domyślnym rozwiązaniem rozstrzygającym konflikty w oparciu o zasadę "późniejszych zwycięstw". Jego inteligentna nazwa to "Microsoft SQL Server DATETIME (później wygrywa) Conflict Resolver", a odpowiedni plik DLL to ssrmax.dll.Jak zaktualizować narzędzie do rozwiązywania konfliktów podczas aktualizacji z SQL-Server 2005 do SQL-Server 2008

Jak wiadomo, po opublikowaniu tabeli z funkcją rozwiązywania konfliktów ten sam program rozpoznawania konfliktów musi być używany we wszystkich późniejszych publikacjach korzystających z tej tabeli. Słusznie, ale podczas dodawania wcześniej publikowanych tabel do nowych publikacji, a określenie bardzo sam konflikt rozpoznawania nazw mają być stosowane do tej tabeli, jesteśmy coraz komunikat o błędzie:

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 

A to błąd otrzymujemy:

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

starając się zrozumieć, jak sam konflikt rozpoznawania nazw nie jest uważany przez maszynę jako „tego samego rezolwerem konfliktów”, odkryłem, że były dwa przeliczniki konflikt o tej samej nazwie, różne wersje, w rejestrze:

th e 2005 wersja:

  • plik ssrmax.dll,
  • wersja 2005.90.4035.0,
  • cls_id D604B4B5-686B-4304-9613-C4F82B527B10

wersja 2008:

  • plik ssrmax.dll,
  • wersja 2009.100.2500.0,
  • cls_id 77209412-47CF-49AF-A347-DCF7EE481277

i zameldowałem, że nasz serwer 2008 rozważa drugi jako 'dostępnej niestandardowego rezolwerem' (mam to uruchamiając sp_enumcustomresolvers). Problem polega na tym, że oba odnośniki są dostępne w rejestrze, więc domyślam się, że stare publikacje odnoszą się do wersji z 2005 roku, podczas gdy nowe publikacje próbują odwołać się do wersji 2008, która faktycznie różni się od poprzedniej.

Pytanie brzmi: w jaki sposób mam serwer rozważyć tylko jedną z tych 2 wersji, i to (oczywiście) bez konieczności upuszczania i odtwarzania istniejących publikacji (które zamieniłyby nasze życie w piekło na następne 2 tygodnie).

Odpowiedz

0

Cóż .. więc nikt nie otrzymał odpowiedzi. Ale myślę, że (w końcu) to dostałem. Zgadnij, co ... jest gdzieś w metamodelu (jak zwykle)!

  • Podczas dodawania pozycji do subskrypcji nowe odwołania do rozwiązywania konfliktów używane przez procedurę przechowywaną pochodzą z [dystrybucji].[MSmerge_articleresolver] tabela
  • Ale dla istniejących zapisów, odwołania resolwera poprzedni konflikt są przechowywane w tabelach systemowych bazy wydawniczej, tj [sysmergearticles], [sysmergeextendedarticlesview] i [sysmergepartitioninfoview]

Więc mamy z jednej strony publikowany jest element początkowo z SQLSERVER 2005, gdzie publikacja odwołuje się do rozwiązywania konfliktów z 2005 r., jak w metamodelu bazy danych. Z drugiej strony maszyna spróbuje dodać ten sam element do nowej publikacji, tym razem z domyślnym odwołaniem do narzędzia do rozwiązywania konfliktów dostępnego w bazie danych dystrybucji, która w rzeczywistości różni się od tej z 2005 ...

Aby to zilustrować, można sprawdzić następujące

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

Następnie

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 

Więc wydaje się, że należy aktualizować albo odniesień w bazie danych dystrybucji lub odniesień w bazie danych publikacji. Spróbujmy!

+0

zrobić, i działa. –

0

Dzięki, miał coś podobnego na re-wydawcy, gdzie artykuł subskrybenta miał identyfikator CLSID, który nie ma sensu na serwerze (wyglądał z Regedit), ale przy próbie dodania artykułu do publikacji wystąpiłby ten błąd.

Updated pole resolver_clsid stołu sysMergeArticles dla subskrybowanego artykułu z clisd został próbuje

{ 

declare @resolver_clsid nvarchar(50) 

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


select @resolver_clsid 

} 

i może następnie dodać artykułowi

Powiązane problemy