Linq-to-sql завершается ошибкой при вставке и обновлении, когда подключен триггер

Question

В последнее время у меня возникают проблемы с linq-to-sql. Проблема в том, что он «думает», что он терпит неудачу при вставках и обновлениях, когда к событию прикреплен триггер. Примером может служить строка, к которой прикреплен триггер для установки двоеточия «LastUpdated» на текущее время, когда строка изменяется. Это заставит linq-to-sql думать, что произошел сбой при обновлении или вставке, но это всего лишь несколько раз, как это иногда случается, я думаю, что это когда сервер sql находится под большой нагрузкой и поэтому не может выполнить триггер до того, как проверка была сделана, это всего лишь предположение. Поскольку мои сценарии являются лишь частью гораздо большего сценария, отключение триггера не является вариантом, поэтому мне нужно найти решение этой проблемы или переписать мою программу. Кто-нибудь из вас сталкивался с этой проблемой и нашел решение, например, отключение проверки после вставки?

Триггер.

USE [cnhha]
GO
/****** Object:  Trigger [dbo].[LastUpdated]    Script Date: 05/12/2011 16:26:51 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER TRIGGER [dbo].[LastUpdated] ON [dbo].[CN_User] 
FOR INSERT, UPDATE
AS

update cn_user set lastupdated=getdate() where campusnetuserid in (select campusnetuserid from inserted)

Answer 1

Возможно, вам нужно SET NOCOUNT ON в вашем триггере

За исключением узкого регистра (SQLDataAdapter), упомянутого в моем вопросе "SET NOCOUNT ON use" , он требуется для большинства клиентских кодов

Вы также можете удалить триггер, если можете изменить UPDATE на стороне клиента для использования ключевого слова DEFAULT

update cn_user
set col1 = this, col2 = that,...,
    lastupdated= DEFAULT
where ...

Answer 2

Ваши триггеры возвращают какие-либо данные через операторы SELECT?См. Эту статью MSDN: CREATE TRIGGER

Когда срабатывает триггер, результаты возвращаются вызывающему приложению, как и в случае хранимых процедур.Чтобы исключить возврат результатов в приложение из-за срабатывания триггера, не включайте ни инструкции SELECT, которые возвращают результаты, ни операторы, которые выполняют назначение переменных в триггере. Триггер, который включает в себя либо операторы SELECT, которые возвращают результаты пользователю, либо операторы, которые выполняют присваивание переменных, требует специальной обработки; эти возвращаемые результаты должны быть записаны в каждом приложении, в котором допускаются изменения в таблице триггеров.Если в триггере должно произойти присвоение переменной, используйте инструкцию SET NOCOUNT в начале триггера, чтобы исключить возврат любых наборов результатов.

Также, если вы считаете, что триггеры вызывают большую нагрузкув ядре базы данных вы рассматривали возможность использования Service Broker для того, чтобы сделать их постобработку асинхронной?

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

Answer 3

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

Answer 4

Вы можете воспользоваться помощью профилировщика SQL для всех действий, происходящих во время процесса. Вы можете собирать и сохранять данные о каждом событии в файл или таблицу.