Автоматически разрешать конфликт слияния первичного ключа

Question

Не могли бы вы предложить мне, как я могу автоматически разрешать конфликты первичных ключей при слиянии между Издателем и Подписчиком.Похоже, что Sql Server не делает этого из коробки: (.

Средство просмотра конфликтов показывает мне следующее сообщение:

Вставка строки в _publisher_server_ не может быть передана в'_subscriber_server_'. Эта ошибка может быть вызвана нарушением ограничения. Нарушение ограничения PRIMARY KEY 'PK_ PartPlan _FD9D7F927172C0B5'. Невозможно вставить повторяющийся ключ в объект '_table_name _'.

Спасибо.

Answer 1

Это не простое решение (поскольку вы, вероятно, уже разработали свою базу данных с автоматически увеличивающимися ключами int), но использование GUID ("uniqueidentifier") для ваших первичных ключей решит проблему коллизии PK.

Answer 2

Самый простой способ, которым я решил эту проблему с помощью ПК с автонумерами, - это изменить приращение числа автонумеров с 1 до 10 (или 100, или 1000, в зависимости от того, что требуется), а затем установить начальное число для всех участников по-разному.

Итак, я могу начать семена:
DB1 при 1
DB2 при 2
DB3 при 3
...
DBn при n (n <приращение) </p>

Например: Приращение 100 даст PK для БД:
DB1 : ** 101, 201, 301 ...
DB2 : ** 102, 202, 302 ...
DB3 : ** 103, 203, 303 ...
Независимо от того, сколько строк INSERT ed, они всегда будут иметь уникальные PK, потому что последние цифры отражают конкретную базу данных.

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

Для существующих таблиц просто сбросьте начальные числа и интервалы PK по сценарию. Это должно быть очень легко сделать.

---

Вы можете использовать GUIDE PK, но использование GUID может быть довольно проблематичным в качестве первичного ключа, особенно если вы также не удаляете его из кластерного индекса. Они также больше, и у вас уже может быть код в зависимости от целых чисел.

Когда вы создаете репликацию слиянием, SQL Server автоматически создает GUID, который он использует для отслеживания изменений, но это не означает, что они должны быть PK

Answer 3

Вы пытались WHEN MATCHED THEN и WHEN NOT MATCHED BY TARGET THEN сделать UPSERT (условное ОБНОВЛЕНИЕ или ВСТАВКА)?

Документация может быть найдена здесь .

Я предполагаю, что первичный ключ представляет один и тот же элемент в обеих БД.