Вдохновленный этот вопрос, где есть разные взгляды на SET NOCOUNT...
Должны ли мы использовать SET NOCOUNT ON для SQL Server? Если нет, почему бы и нет?
Что он делает Редактировать 6, 22 июля 2011 г.
Он подавляет сообщение "xx rows affected" после любого DML. Это набор результатов, и при отправке клиент должен его обработать. Он крошечный, но измеримый (см. Ответы ниже)
Для триггеров и т.д. клиент получит несколько "xx rows affected", и это вызывает всевозможные ошибки для некоторых ORM, MS Access, JPA и т.д. (см. правки ниже)
Фон:
Общепринятая лучшая практика (я думал до этого вопроса) заключается в использовании SET NOCOUNT ON
в триггерах и хранимых процедурах в SQL Server. Мы используем его повсеместно, и быстрый Google показывает, что большое количество MVP-клиентов SQL Server тоже соглашаются.
MSDN говорит, что это может сломать .NET SQLDataAdapter.
Теперь это означает, что SQLDataAdapter ограничен исключительно обработкой CRUD, потому что он ожидает, что сообщение "n rows affected" будет соответствовать. Поэтому я не могу использовать:
- IF EXISTS, чтобы избежать дублирования (нет сообщений, затрагивающих строки) Примечание: используйте с осторожностью
- ГДЕ НЕ СУЩЕСТВУЕТ (меньше ожидаемых строк
- Отфильтруйте тривиальные обновления (например, данные фактически не изменяются)
- Предоставляет ли какой-либо доступ к таблице до (например, ведение журнала)
- Скрыть сложность или denormlisation
- и т.д.
В вопросе marc_s (кто знает свой SQL-материал) говорит, что не используйте его. Это отличается от того, что я думаю (и я считаю себя достаточно компетентным в SQL тоже).
Возможно, что я что-то упустил (не стесняйтесь указать на очевидное), но что вы думаете, думают ли вы?
Примечание: прошло много лет с тех пор, как я увидел эту ошибку, потому что сейчас я не использую SQLDataAdapter.
Редактирование после комментариев и вопросов:
Изменить: Больше мыслей...
У нас есть несколько клиентов: можно использовать С# SQLDataAdaptor, другой может использовать nHibernate из Java. Они могут быть затронуты по-разному с помощью SET NOCOUNT ON
.
Если вы считаете хранимые procs как методы, то плохая форма (анти-шаблон) для принятия некоторой внутренней обработки работает определенным образом для ваших собственных целей.
Изменить 2: a триггер, разбивающий вопрос nHibernate, где SET NOCOUNT ON
не может быть установлен
(и нет, это не дубликат этого)
Редактировать 3: Еще больше информации, благодаря моему коллеге MVP
- KB 240882, вызывающий разъединения на SQL 2000 и ранее
- Демо-версия производительности
Редактировать 4: 13 мая 2011 г.
Перерывы Linq 2 SQL тоже не заданы?
Редактировать 5: 14 июня 2011 г.
Разрывает JPA, хранит proc с переменными таблицы: Поддерживает ли JPA 2.0 переменные таблицы SQL Server?
Редактировать 6: 15 августа 2011
В сетке данных SSMS "Редактировать строки" требуется SET NOCOUNT ON: Обновить триггер с GROUP BY
Редактировать 7: 07 Март 2013 г.
Подробнее о деталях от @RemusRusanu:
Действительно ли SET NOCOUNT ON делает большую часть разницы в производительности.