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