Как обойти триггер на SQL Server 2008

Question

Я хочу обойти триггер в некоторых случаях, может ли кто-нибудь помочь мне в этом?

Я пытаюсь использовать по этой ссылке , но не могу найти решение.

Заранее спасибо

Answer 1

Шаг 1 Отключить триггер

DISABLE TRIGGER Person.uAddress ON Person.Address;

http://msdn.microsoft.com/en-us/library/ms189748.aspx

Шаг 2 Сделать вещи

UPDATE Person.Address SET HouseNumber = REPLACE(HouseNumber, ' ', '');

Шаг 3 Включить триггер

ENABLE Trigger Person.uAddress ON Person.Address;

http://msdn.microsoft.com/en-us/library/ms182706.aspx

- Должен сказать, используйте с осторожностью!

Answer 2

Вы не можете избежать запуска триггера. Что вы можете сделать, это добавить в него условия, например:

CREATE TRIGGER trigger_name
   ON table
   AFTER INSERT 
AS
begin
   IF (your condition) begin
     --code
   END
end

только будьте осторожны, если у вас есть триггер INSTEAD OF. Если вы не закодируете вставку, ничего не будет вставлено в таблицу.

Answer 3

Вы можете отключить триггер, проверив наличие временной таблицы.Код, для которого нужно подавить триггер, должен создать временную таблицу (скажем, #suppress_trigger).В вашем триггере проверьте наличие этой временной таблицы и верните.Пример:

CREATE TABLE [dbo].[dummy](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [Val] [char](1) NULL)   

--create a history table which gets populated through trigger
CREATE TABLE [dbo].[dummy_hist](
[Id] [int] NULL,
[Val] [char](1) NULL) 

CREATE TRIGGER [dbo].[trig_Insert]
   ON  [dbo].[dummy]    
   AFTER INSERT
AS 
BEGIN

    SET NOCOUNT ON;
    if OBJECT_ID('tempdb..#Dummy_escape_trig') is not NULL
        RETURN

    INSERT INTO dummy_hist
    SELECT * FROM inserted

END

--Proc for which trigger needs to be suppressed
CREATE PROCEDURE [dbo].[ins_dummy]
        @val AS CHAR(1)
AS
BEGIN

    SET NOCOUNT ON;    

    CREATE TABLE #Dummy_escape_trig (id int)

INSERT INTO dummy
    VALUES(@val)
END

Answer 4

@ Маниш: Я не думаю, что обход триггера был бы хорошим вариантом с точки зрения передового опыта. Вместо этого я бы оценил, учел и отфильтровал набор условий, необходимых для срабатывания триггера.

Answer 5

Существуют некоторые практические проблемы с отключением триггера в производственной среде. Я предполагаю, что вы будете специально отключать триггеры таблиц (в отличие от базы данных или всего сервера):

1. Вам нужны разрешения ALTER для таблицы, на которой вы работаете. Это обычно считается проблематичным по соображениям безопасности. Это становится намного более проблематичным на уровне базы данных и сервера.
2. Отключение не ограничено вашим конкретным подключением / сеансом, но повлияет на все события, которые запускают триггер, из любых сеансов, пока он отключен. Если вы ожидаете параллелизма в рассматриваемом коде, вы должны предположить, что тот же код будет вызываться из других потоков. Чего не хватает в предыдущих предложениях, так это полного рассмотрения управления параллелизмом, которого требует использование любого семафора. В частности, эта временная таблица определяет семафор для защищенного раздела кода (в смысле многопоточности), где семафор - это существование временной таблицы. Если вы на самом деле отключаете триггер, то для правильного использования этой временной таблицы по прямому назначению необходимо провести тест непосредственно перед тем, как защищенный код создаст временную таблицу, чтобы проверить, существует ли она уже. Для этого может потребоваться глобальная временная таблица, или вы можете выполнить более умный поиск в базе данных tempdb, чтобы увидеть, существует ли она в каком-либо сеансе. Защищенный код должен проверить, существует ли семафор, и войти в состояние блокировки, если он намеревается дождаться, когда ресурс (в данном случае триггер) будет доступен, как и ожидалось. Это становится сложным, и имеет небольшую ценность в обмен на сложность.

Мнение. Несмотря на то, что триггеры легко отключить / включить, есть много соображений, которые следует соблюдать осторожно, если вы временно отключите их как часть какого-то конкретного варианта использования, поскольку это разработка стратегии управления параллелизмом.

Если вы не достаточно комфортно разбираетесь в управлении параллелизмом или если у вас нет абсолютно никаких требований к тому, чтобы код был реентерабельным / параллельным, у вас (вероятно, спорадически) будут проблемы, если вы используете DISABLE TRIGGER, но не не учитывать эти факторы.

Самый безопасный путь, который я вижу, учитывая все это, - это не отключать триггер, использовать локальную временную таблицу в качестве семафора, который влияет только на текущий сеанс, тщательно кодировать код выхода, чтобы временная таблица была определенно уничтожена при конец защищенного кода, как уже предлагалось, но он все еще требует проверки / блокировки, даже если это будет иметь значение только при одном и том же соединении и, в частности, при параллельном выполнении на одном и том же соединении. Абсолютно безопасный способ сделать это - создать sproc только для защищенного кода. Sproc проверяет / блокирует, затем, если он продолжается (и вам нужно будет проверить наличие тупиковой ошибки после выхода из кода блокировки), создает временную таблицу. Так как временные значения уничтожаются при возврате sproc, любой путь из защищенного кода будет обрабатывать семафор. Но временные таблицы доступны в течение сеанса - не только внутри sproc (пока sproc работает), либо даже внутри пакета. SQL Server поддерживает параллельные запросы для одного сеанса, поэтому временная таблица, созданная в одном потоке сеанса, видна в любом другом. Это означает, что он может быть замечен вне sproc в том же сеансе, и фактически, тот же самый код может быть запущен в это время. Вот почему в этом сценарии вам по-прежнему необходимо реальное управление параллелизмом.

И, наконец, мои извинения за запутанный комментарий. Я считаю, что почти каждое обсуждение многопоточности и управления параллелизмом превращается в это, потому что, хотя концепции не так уж и сложны, методы кодирования долгое время считались деликатными и хрупкими и подвержены ошибкам разработчика.