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

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

Триггер.

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)

Ответы

Ответ 1

Вероятно, вам понадобится SET NOCOUNT ON в вашем триггере

За исключением узкого случая (SQLDataAdapter), упомянутого в моем вопросе "УСТАНОВИТЬ НАКОПЛЕНИЕ ON использования" , он необходим для большинства клиентских кодов

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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