Записи не реплицируются при вставке с помощью хранимой процедуры пользовательской репликации - PullRequest
1 голос
/ 11 октября 2008

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

Моя проблема возникает при попытке реплицировать таблицу журнала обратно в основную базу данных публикации. Вот что я сделал:

  1. В базе данных, в которой находится таблица журнала, я настраиваю новую репликацию транзакций и устанавливаю ее для создания моментального снимка.
  2. После создания публикации я создаю новую push-подписку и настраиваю ее на немедленную инициализацию.
  3. После создания подписки я проверил состояние синхронизации и подтвердил, что моментальный снимок успешно применен.

Теперь вот странная часть: если я вручную добавлю запись в таблицу журнала с помощью SQL Server Management Studio, запись будет реплицирована нормально. Если запись добавлена ​​хранимой процедурой пользовательской репликации, она не будет. В статусе всегда будет отображаться «Реплицированные транзакции недоступны».

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

Может кто-нибудь объяснить, что я сделал не так?

ОБНОВЛЕНИЕ: У меня, наконец, есть ответ на эту проблему несколько месяцев назад, просто я так и не нашел время обновить этот вопрос. Мы должны зарегистрировать звонок в службу поддержки Microsoft, но у нас есть работающее решение.


ОТВЕТ: Чтобы решить проблему, при добавлении подписки, вам нужно запустить скрипт, как показано ниже:
sp_addsubscription @publication = 'TEST', ..., @loopback_detection = 'false'

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

Ответы [ 2 ]

1 голос
/ 16 марта 2009

У меня, наконец, есть ответ на эту проблему несколько месяцев назад, просто я так и не нашел время обновить этот вопрос. Мы должны зарегистрировать звонок в службу поддержки Microsoft, но у нас есть работающее решение.

Чтобы решить эту проблему, при добавлении подписки необходимо запустить скрипт, как показано ниже:

sp_addsubscription @publication = 'TEST', ..., @loopback_detection = 'false'

Ключом к решению является последний параметр, показанный выше: @ loopback_detection = 'false' . По умолчанию сгенерированный сценарий подписки не будет иметь этот параметр.

0 голосов
/ 09 февраля 2009

Я вижу, что это очень старый вопрос, поэтому вы, вероятно, решили это, но в любом случае ...

Проблема, которую вы описываете, безусловно, не имеет смысла. Репликация будет вызываться в дальнейшем при любых изменениях исходной таблицы через триггер репликации. Единственное, что не выглядит правильно в вашем описании процесса (хотя я, возможно, неправильно читаю), - это то, что вы создаете снимок, прежде чем нажать на подписку. Обычно вы должны настроить репликацию, нажать подписку, а затем создать / отправить снимок. Не доверяйте статусу синхронизации, так как он ничего не проверяет, он просто говорит, что у него нет транзакций для копирования, он не знает, что таблицы синхронизируются.

Что касается того, почему ваша ручная вставка работает, а не автоматическая, я бы проверил и перепроверил вашу работу, так как принципиально, если репликация работает, то любое изменение в этой таблице будет реплицировано, независимо от источника.

Если вы давно решили это, мне было бы интересно услышать решение.

Edit:

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

...