Как обновить разрешение конфликта при обновлении с SQL Server 2005 до SQL-Server 2008

Question

Недавно мы обновили с SQL Server 2005 до SQL Server 2008 (R2, SP1). Это обновление включало некоторые публикации, в которых публикуются все таблицы с помощью разрешения конфликтов по умолчанию, основанного на принципе «более поздних выигрышей». Его интеллектуальное имя - «Microsoft SQL Server DATETIME (позже выигрывает)« Реабилитатор конфликтов », а соответствующий DLL-файл - ssrmax.dll.

Как вы знаете, как только таблица будет опубликована с помощью разрешения конфликта, тот же конфликтный разрешитель должен использоваться во всех последующих публикациях, используя эту таблицу. Справедливо, но при добавлении ранее опубликованных таблиц в новых публикациях, и указав тот же распознаватель конфликта, которые будут использоваться для этой таблицы, мы получаем сообщение об ошибке:

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 

И это ошибка, мы получим:

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

пытаясь понять, как же распознаватель конфликта не рассматриваются машина как «то же распознаватель конфликта», я обнаружил, что там было два конфликт резольверов с тем же именем, различными версиями, в реестре:

th е версии 2005:

• файл ssrmax.dll,
• версия 2005.90.4035.0,
• cls_id D604B4B5-686B-4304-9613-C4F82B527B10

версия 2008:

• file ssrmax.dll,
• версия 2009.100.2500.0,
• cls_id 77209412-47CF-49AF-A347-DCF7EE481277

И я проверил, что наш сервер 2008 рассматривает второй как «доступный пользовательский распознаватель» (я получил это, запустив sp_enumcustomresolvers). Проблема в том, что обе ссылки доступны в реестре, поэтому я думаю, что старые публикации относятся к версии 2005 года, в то время как новые публикации пытаются ссылаться на версию 2008 года, которая действительно отличается от предыдущей.

Итак, вопрос в том, как сервер может рассматривать только одну из этих двух версий, и это (разумеется), без необходимости отбрасывать и воссоздавать существующие публикации (что превратит нашу жизнь в ад для следующих 2 недель).

Answer 1

Хорошо, поэтому никто не получил ответа. Но я думаю, что (наконец) понял. Угадайте, что ... это где-то в метамодели (как обычно)!

• При добавлении элемента в подписку новые ссылки на разрешение конфликтов, используемые хранимой процедурой, поступают из [распределения].[MSmerge_articleresolver] стол
• Но для существующих подписок, ссылки распознавателя предыдущего конфликта сохраняется в системных таблицах издательской базы данных, то есть [sysmergearticles], [sysmergeextendedarticlesview] и [sysmergepartitioninfoview]

Таким образом, мы имеем с одной стороны, начальный элемент, опубликованный с SQLSERVER 2005, где публикация ссылается на решатель конфликта 2005 года, согласно метамодели публикации базы данных. С другой стороны, машина попытается добавить один и тот же элемент в новую публикацию, на этот раз с ссылкой по умолчанию на разрешающую способность конфликта, доступную в базе данных распределений, которая действительно отличается от версии 2005 года.

Чтобы проиллюстрировать это, вы можете проверить следующее

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

Затем

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 

Таким образом, кажется, что я должен обновить либо ссылки в базе данных распространителя или ссылки в базе данных публикации. Давайте попробуем!

Answer 2

Спасибо, было что-то похожее на переиздатель, где у статьи подписчика был CLSID, который не имел никакого смысла на сервере (смотрел с Regedit), но при попытке добавить статью в публикацию произведет указанную ошибку.

Обновленный resolver_clsid поле sysMergeArticles таблицы для подписного статьи с clisd он пытается получить

{ 

declare @resolver_clsid nvarchar(50) 

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


select @resolver_clsid 

} 

, а затем может добавить статью