Clique no banner para conhecer e adquirir o meu treinamento de Bancos de Dados no Azure

SQL Server – Como identificar a query que disparou uma trigger de DML numa tabela

Post Views 1,498 views
Reading time 5 minutes

Como identificar a query que disparou uma trigger de DML numa tabela? Li essa dúvida num grupo do Telegram e resolvi escrever um artigo sobre isso.

Introduction

Como vocês sabem, existem várias soluções para se implementar um log de auditoria com as alterações de dados em uma determinada tabela:

Uma das soluções mais utilizadas para isso, é a utilização de triggers de DML (Saiba como implementar isso clicando aqui)

Em alguns cenários, é importante identificar qual a consulta que acabou disparando a trigger para talvez identificar a origem dos dados que estão sendo inseridos a partir do SQL. E é isso que aprenderemos como fazer nesse post.

Caso você queira mais detalhes da origem desse comando e identificar toda a cadeia de execução da trigger, sugiro a leitura do artigo SQL Server – Como identificar e monitorar a execução de triggers.

Creating the test base

Para a demonstração dos códigos desse artigo, vou compartilhar com vocês o script que utilizei para montar essa tabela e a trigger utilizada para auditar as alterações. Vou utilizar o mesmo exemplo do artigo SQL Server – Como criar um histórico de alterações de dados para suas tabelas (logs para auditoria).

Criação das tabelas
Clique aqui para visualizar código da criação das tabelas

Criação da trigger:
Clique aqui para visualizar o código da trigger

Faço algumas alterações na tabela original:

E podemos ver que a auditoria está funcionando conforme o esperado:

Como identificar a query que disparou a trigger

Agora descobriremos como identificar a query que disparou a trigger.

Para isso, vamos alterar a trigger e incluir o comando INPUTBUFFER para capturar a query e armazenar essa informação na tabela de log.

A sintaxe de utilização do comando é assim:

Adicionaremos o campo que armazenará a query na tabela:

E agora alteramos a trigger:
Clique aqui para visualizar código da trigger

E vamos testar novamente executando o comando abaixo:

Result:

Como as 2 instruções SQL foram executadas juntas, no mesmo batch, o comando INPUTBUFFER capturou os 2 comandos de uma vez. Se eu tentar executar novamente, mas utilizando um GO para separar os blocos ou mesmo, executando separadamente, podemos observar que a trigger agora vai identificar corretamente os comandos de cada instrução:

Result:

E se tiver outra trigger, em outra tabela, que está alterando a tabela Cliente e você não está conseguindo identificar de onde vem esse comando?

Primeiro, criaremos uma tabela com dados de funcionários:

Agora criarei uma trigger nessa nova tabela que atualiza a tabela Cliente caso o cliente e o funcionário tenham o mesmo nome:

Ao executar um simples comando de UPDATE, veremos que a trigger foi disparada nas duas tabelas

Result:

Que legal! Mesmo o comando vindo de outra trigger, foi possível identificar a origem dessa alteração.

Mas e se você quiser mais detalhes da origem desse comando e identificar toda a cadeia de execução da trigger? Bom, neste caso, sugiro a leitura do artigo SQL Server – Como identificar e monitorar a execução de triggers.

Espero que vocês tenham gostado desse artigo e até a próxima 🙂
Abraços!