Системные триггеры для репликации и опция NOCOUNT

Question

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

Можно ли ожидать, что поведение системных триггеров будет использоваться SET NOCOUNT ON, чтобы предотвратить их действия, влияющие на значение функции @@ROWCOUNT?

фон

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

Без репликации все работает нормально, но с репликацией строки NHibernate повлияли на проверки проверки. Количество строк, которые ADO.Net говорит, что это повлияло, похоже, включает строки, затронутые связанным триггером, в дополнение к строкам, затронутым самой командой.

В исходном вопросе я упомянул функцию сервера Sql @@ROWCOUNT, но я действительно имею в виду значение «rows affected», возвращаемое методом ADO.Net ExecuteNonQuery. Я полагаю, что я работал над предположением (возможно, неправильно), что тот был подан первым.

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

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

В настоящее время мы изучаем варианты, которые включают расширение NHibernate, чтобы добавить способность справляться с этим или, по крайней мере, подавлять это. Наши ресурсы включают this SO question.

Я также нашел this post, который предположил, что сгенерированные системой триггеры уже установили опцию NOCOUNT в положение ON по умолчанию, отрицая необходимость их изменения. Для нас это определенно не так, поэтому я задавался вопросом, почему это может быть.

1. Какова ситуация по умолчанию в отношении сгенерированных системой триггеров?
2. Является ли поведение настраиваемым?
3. Это зависит от типа репликации - слияния, транзакции?

Answer 1

Я не смог определить ответ на исходный вопрос - (должен/может/как). Сгенерированные триггеры репликации системы Sql Server автоматически включают опцию SET NOCOUNT ON.

Наша команда DBA предлагает ответ: нет. Они также говорят (совершенно справедливо), что они не будут настраивать системные триггеры на производстве.

Варианты, оставленные открытыми для меня, являются ...

1. Измените/увеличьте NHibernate, чтобы не выбрасывать TooManyRowsAffectedException, когда обнаружено несоответствие числа строк.
2. Извлеките NHibernate и замените хранимые процедуры и ручное сопоставление бизнес-объектов.

Мы выбрали вариант 1.

мое решение было изменить NHibernate (2,1) Core, следующим образом ...

1. Сначала я добавил новую опцию конфигурации, чтобы контролировать свой новое поведение.
2. Затем я изменил подпись методов VerifyOutcomeNonBatched и VerifyOutcomeBatched класса NHibernate.AdoNet.Expectations, чтобы принять новое значение конфигурации в качестве параметра. Это включало изменение нескольких мест, где эти методы называются.
3. Наконец, я изменил эти два метода, чтобы каждый из них выбрал/подавил TooManyRowsAffectedException в соответствии с опцией конфигурации.

Меня интересовали бы любые предлагаемые альтернативные варианты.