При параллельном сохранении Entity.Save() с использованием параллельных потоков Parallel.ForEach получаю ошибку:
System.Data.SqlClient.SqlException: A trigger returned a resultset and/or was running with SET NOCOUNT OFF while another outstanding result set was active.
Как установить NOCOUNT ON для объекта Entity при сохранении?
Проблема возникает из-за того, что в каком-то триггере в базе данных для таблицы, связанной со схемой Entity не установлен SET NOCOUNT ON.
Для решения проблемы Вам нужно определить, что это за триггер и внести в него изменения.
У меня, например, такая проблема воспроизводилась при попытке удалить бизнес-процесс из конфигураци и возникала для объекта Contact. Для этой таблицы в БД есть триггер завязанный на изменение (UPDATE), но в нем не было установлено SET NOCOUNT ON.
Возможно, что у Вас также проблема именно в этом триггере.
Это зависит от того, о каком триггере речь. Генерировался ли он автоматически ядром, или создан специально для этой таблицы разработчиками вручную.
В первом случае менять нежелательно, во втором — нужно будет быть осторожным при установке обновлений, если в пакете будет SQL-запрос обновления стандартного триггера.
Узнать, что это за триггер, можно, наблюдая запросы в профайлере.
Это стандартная логика, связанная с поиском дублей и полем-изображением. Из трёх триггеров на событии вставки и изменения работает только один, обновляющий изображение.
Если дорабатывать или отключать триггер не хотите и сбой наблюдается только после Ваших доработок, есть смысл их переделать на последовательное изменение записей.
Суть ошибки я понимаю. Вопрос в другом имеем ли мы право вносить правки в системные триггер.
Да, исправления нужно внести обязательно, так как это ошибка. Уверенна, что никаких критических проблем не возникнет, однако сначала выполните эти исправления на тестовой базе, протестируйте, а потом переносите на прод.
Решением будет удаление некорректных сторонних доработок, которые ломают стандартную логику триггеров раздела. В конфигурации вообще использование Parallel.ForEach минимально, только один раз при работе с сервисом рассылок.
Вы можете производить ресурсоемкие манипуляции в отдельной оперативной таблице, а затем в моменты минимальной нагрузки заливать последовательно данные оттуда в основную.
