Ao fazer gatilhos de fogo e quando não fazem

Question

pergunta muito geral sobre disparadores no servidor SQL 2005.

Em que situações são gatilhos da tabela demitido e que situações não são?

Qualquer exemplos de código para demonstrar seria ótimo.

Eu estou escrevendo bancos de dados baseados uma auditoria e só quero estar ciente de quaisquer situações que podem não disparar os gatilhos que eu configurei para atualizar, apagar e inserir nas minhas tabelas.

Um exemplo do que quero dizer,

UPDATE MyTable SET name = 'test rows' WHERE id in (1, 2, 3);

A seguinte declaração só é acionado o gatilho atualização uma vez.

Answer 1

Quando você quer que eles fogo?

CREATE TRIGGER AFTER ACTION

que após executar a ação (insert update delete) sendo cometido. INSTEAD OF dispara o gatilho no lugar da ação.

Uma das maiores armadilhas com gatilhos é que eles dispara sempre que uma ação é executada, , mesmo que nenhuma linha é afetada . Este não é um bug, e é algo que pode queimá-lo muito rapidamente se você não for cuidadoso.

Além disso, com gatilhos, você poderá usar as tabelas inserted e deleted. linhas atualizadas estão listadas em ambos. Isso gera um monte de gente fora, porque eles não estão acostumados a pensar sobre um update como um delete então insert.

A documentação MSDN realmente tem uma discussão muito aprofundada sobre quando gatilhos fogo e qual o efeito que eles têm aqui .

Answer 2

Em 2008, você pode usar construído em Change Data Capture

Além disso, existem algumas situações em que gatilhos não fazer fogo, tais como:

· Uma tabela é descartado.

· Uma tabela é truncado.

· Configurações para disparadores aninhados e / ou recursiva evitar um gatilho de disparar.

· Os dados são carregados a granel, ignorando disparadores.

Answer 3

A seguinte declaração só é acionado o gatilho atualização uma vez.

Qualquer declaração tipo de ação só é acionado o gatilho uma vez, não importa quantas linhas são afetados, gatilhos deve ser escrito para lidar com várias inserções de linha / atualizações / exclusões.

Se o seu gatilho depende de apenas uma linha de cada vez estar nas pseudotables inseridas ou excluídas, ele irá falhar. E pior que não vai falhar com um erro, ele simplesmente não vai afetar todas as linhas que deseja afetadas por qualquer que seja o gatilho faz. Não corrigir isso através de um loop ou um cursor em um gatilho, mude para a lógica baseada em conjunto. Um cursor em um gatilho pode trazer seu aplicativo inteiro a uma parada brusca enquanto uma transação de 500.000 processos de registros e trava a mesa durante horas.

inserções em massa por gatilhos de passagem a menos que você especificar para usá-los. Esteja ciente disso, porque se você deixá-los by pass o gatilho será necessário código para certificar-se de tudo o que acontece no gatilho também acontece após a inserção em massa. Ou você precisa chamar as inserções em bloco com a opção FIRE_TRIGGERS.

Answer 4

Eu pensei em destacar a partir do link Eric postou uma situação na qual um gatilho não iria fogo:

Apesar de uma declaração TRUNCATE TABLE está em vigor um DELETE, não pode ativar um gatilho porque a operação não registra exclusões de linha individuais. No entanto, apenas aqueles com permissões em uma tabela para executar um TABLE TRUNCATE precisa se preocupar com inadvertidamente contornar um gatilho DELETE com uma declaração TRUNCATE TABLE.