MS-SQL Server 2005: неконвергентные данные после репликации

У нас есть топология репликации слиянием, включающая одного издателя, несколько публикаций и несколько подписок. Работает без проблем не менее 8 месяцев.

Несколько дней назад мне сообщили, что мои коды заказа на поставку без каких-либо причин "изменяются" со стандартного стиля "ZWWTP / PO-0092" на новый стиль "ZWWT": символы с 5 по 8 в коде заказа на поставку были изменены на другая строка - chr (0) & chr (1) & chr (0) & chr (1) на некоторых серверах

Я дошел до точки, когда оказалось, что только один из моих процессов репликации / подписки генерировал такие фиктивные данные: коды PO на издателе и этом конкретном подписчике больше не соответствовали недавно обновленным или добавленным записям. Коды для заказов, созданных на стороне подписчика, будут изменены при загрузке на издателя (оставаясь чистыми для подписчика). Заказы на покупку, загруженные с издателя, будут распространяться на подписчика с измененным кодом заказа.

Затем я смог очистить / скорректировать данные на обоих серверах с помощью некоторых утилит сравнения таблиц + некоторых операторов UPDATE, но одни и те же расхождения теперь появляются каждый раз, когда репликация выполняется между двумя серверами: мои чистые / идентичные данные на обоих серверах будут вернуться в неконвергентное состояние после успешного выполнения репликации: те же записи, те же значения!

Не думаю, что я оставил в сети много доступных ресурсов, касающихся конвергенции и репликации данных. Ничего не нашел. Я планирую выбросить / восстановить существующую публикацию / подписку за 3 часа, но я все еще ищу рациональный ответ на мою проблему, прежде чем она превратится в психоаналитическую проблему:

Кто-нибудь знает, что происходит?

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

Обновлено: ну, я сделал это, и это НЕ РАБОТАЕТ! Я выбросил и подписку, и публикацию, воссоздал публикацию, но тогда мне не удалось создать снимок. Серверу не удалось управлять тем, что он называет «записью распределения диапазона идентификаторов для издателя», что «не удалось найти в системной таблице MSmerge_identity_range.

После просмотра я обнаружил, что этот статья говорит, что такая проблема может возникнуть, когда «вы удалили первую публикацию, созданную в базе данных публикации».

Как это смешно! Это именно то, что я только что сделал!

К счастью, эта проблема должна быть решена с помощью накопительного пакета SQLServer 2005 5, который мне все еще нужно загрузить и установить. Но теперь возникает вопрос: как пользователи SQLServer 2005 могли работать до выпуска этого CP5?

EDIT2: накопительный пакет 5 не работал, и я все еще не могу создать снимок для моей новой репликации!