Compartilhar via

Armadilhas na programação de procedimentos de gatilho

  • Artigo

Introdução

Participar dos fóruns de SQL Server é uma forma de agilizar o aprendizado de T-SQL, pois há uma variedade de ambientes e situações. Ao longo do tempo observa-se que há alguns temas que são recorrentes, com maior número de perguntas. Um destes temas refere-se à programação de procedimentos trigger, isto é, procedimentos armazenados que são executados automaticamente quando determinado gatilho é disparado.

Nesta série de artigos sobre trigger, em cada artigo será selecionada pergunta postada no fórum sobre o tema, servindo de desenvolvimento para o texto do artigo. Serão indicados erros presentes no código apresentado pelo autor e apresentadas possíveis soluções. Desta forma, o assunto será aprofundado gradativamente.

Esta série de artigos não pretende ser material conceitual sobre procedimento trigger, mas no final deste wiki há uma série de referências para quem necessite de conhecimento básico sobre o assunto. É assumido que o leitor possui conhecimento básico de programação em T-SQL.

Conforme documento Gatilhos DML, “Os gatilhos DML são um tipo especial de procedimento armazenado que entra em vigor automaticamente quando um evento DML (linguagem de manipulação de dados) ocorre e afeta a tabela ou exibição definida no gatilho. Os eventos DML são instruções INSERT, UPDATE ou DELETE”.

Os gatilhos podem ser do tipo AFTER, quando “são executados depois que a ação das instruções INSERT, UPDATE ou DELETE é executada” ou então do tipo INSTEAD OF, quando “substituem as ações padrão da instrução de gatilho”.

As instruções de gatilho DML usam duas tabelas especiais, INSERTED e DELETED, que são tabelas virtuais que somente têm existência enquanto o procedimento armazenado está em execução, acionado pelo respectivo gatilho DML. A tabela DELETED armazena cópias das linhas afetadas pelas instruções DELETE e UPDATE, antes da execução da instrução. A tabela INSERTED armazena cópias das linhas afetadas, após a execução das instruções INSERT e UPDATE. Desta forma, no caso da instrução UPDATE tem-se a imagem antes da atualização (na tabela DELETED) e após a atualização (na tabela INSERTED).

É possível utilizar o conteúdo dessas tabelas virtuais para testar os efeitos de algumas modificações de dados e para definir critérios para ações do procedimento armazenado associado ao gatilho.

Deve-se ter especial atenção ao fato de que o procedimento associado ao gatilho é acionado uma única vez para cada execução da instrução DML que manipule a tabela associada ao gatilho.

Estudo de casos

Caso 1

Trata-se de um caso em que o procedimento de gatilho emite a mensagem "A subconsulta retornou mais de 1 valor" sempre que ocorre tentativa de incluir mais de uma linha na mesma instrução INSERT.

Acesse Armadilhas na programação de procedimentos de gatilho [caso 1].

Caso 2

Trata-se de caso em que o procedimento de gatilho para DELETE e que funciona parcialmente: quando mais de uma linha é apagada em uma mesma instrução DELETE, somente em uma das linhas é realizada a ação desejada.

Acesse Armadilhas na programação de procedimentos de gatilho [caso 2].

Caso 3

Trata-se de caso em que o procedimento trigger não funciona corretamente quando mais de uma linha é apagada na tabela. Este é um procedimento de gatilho que atende ações do tipo INSERT, DELETE e UPDATE.

Acesse  Armadilhas na programação de procedimentos de gatilho [caso 3].

Caso 4

Trata-se de caso de migração de procedimentos de gatilho, de MySQL para SQL Server. As observações se aplicam também para a migração de Oracle Database para SQL Server.

Acesse  Armadilhas na programação de procedimentos de gatilho [caso 4].

Referências

Documentação BOL

Artigo completo

  • clique aqui para obter o artigo completo (todos os casos) em formato PDF

Artigos sobre o assunto