Passando informações sobre quem excluiu o registro para um gatilho Excluir

Ao configurar uma trilha de auditoria, não tenho problemas em rastrear quem está atualizando ou inserindo registros em uma tabela; no entanto, rastrear quem exclui registros parece mais problemático.

Eu posso rastrear Inserções / Atualizações incluindo no campo Inserir / Atualizar o "Atualizado por". Isso permite que o acionador INSERT / UPDATE tenha acesso ao campo "UpdatedBy" via inserted.UpdatedBy. No entanto, com o gatilho Excluir, nenhum dado é inserido / atualizado. Existe uma maneira de passar informações para o gatilho Excluir, de modo que ele possa saber quem excluiu o registro?

Aqui está um gatilho Inserir / Atualizar

ALTER TRIGGER [dbo].[trg_MyTable_InsertUpdate] 
ON [dbo].[MyTable]
FOR INSERT, UPDATE
AS  

INSERT INTO AuditTable (IdOfRecordedAffected, UserWhoMadeChanges) 
VALUES (inserted.ID, inserted.LastUpdatedBy)
FROM inserted 

Usando o SQL Server 2012

Existe uma maneira de passar informações para o gatilho Excluir, de modo que ele possa saber quem excluiu o registro?

Sim: usando um recurso muito interessante (e subutilizado) chamado CONTEXT_INFO. É essencialmente a memória da sessão que existe em todos os escopos e não é vinculada por transações. Ele pode ser usado para transmitir informações (qualquer informação - bem, qualquer que se encaixe no espaço limitado) para acionadores, bem como para frente e para trás entre chamadas subprocessos / EXEC. E eu o usei antes para exatamente essa mesma situação.

• As informações de contexto são VARBINÁRIAS (128)

• Definido via: SET CONTEXT_INFO

• Obter via: CONTEXT_INFO ()

Teste com o seguinte para ver como funciona. Observe que estou convertendo para CHAR(128)antes do CONVERT(VARBINARY(128), ... Isso é forçar preenchimento em branco para facilitar a conversão VARCHARquando retirá-lo, CONTEXT_INFO()pois VARBINARY(128)é preenchido com 0x00s.

SELECT CONTEXT_INFO();
-- Initially = NULL

DECLARE @EncodedUser VARBINARY(128);
SET @EncodedUser = CONVERT(VARBINARY(128),
                            CONVERT(CHAR(128), 'I deleted ALL your records! HA HA!')
                          );
SET CONTEXT_INFO @EncodedUser;

SELECT CONTEXT_INFO() AS [RawContextInfo],
       RTRIM(CONVERT(VARCHAR(128), CONTEXT_INFO())) AS [DecodedUser];

Resultados:

0x492064656C6574656420414C4C20796F7572207265636F7264732120484120484121202020202020...
I deleted ALL your records! HA HA!

COLOCANDO TUDO JUNTO:

1. O aplicativo deve chamar um procedimento armazenado "Excluir" que transmita o nome de usuário (ou o que for) que está excluindo o registro. Presumo que este já seja o modelo que está sendo usado, pois parece que você já está acompanhando as operações de Inserir e Atualizar.

2. O procedimento armazenado "Excluir" faz:

   DECLARE @EncodedUser VARBINARY(128);
   SET @EncodedUser = CONVERT(VARBINARY(128),
                               CONVERT(CHAR(128), @UserName)
                             );
   SET CONTEXT_INFO @EncodedUser;
   
   -- DELETE STUFF HERE
   

3. O gatilho de auditoria faz:

   -- Set the INT value in LEFT (currently 50) to the max size of [UserWhoMadeChanges]
   INSERT INTO AuditTable (IdOfRecordedAffected, UserWhoMadeChanges) 
      SELECT del.ID, COALESCE(
                        LEFT(RTRIM(CONVERT(VARCHAR(128), CONTEXT_INFO())), 50),
                        '<unknown>')
      FROM DELETED del;
   

4. Observe que, como o @SeanGallardy apontou em um comentário, devido a outros procedimentos e / ou consultas ad hoc para excluir registros desta tabela, é possível que:

   • CONTEXT_INFOnão foi definido e ainda é NULL:

     Por esse motivo, atualizei o acima INSERT INTO AuditTablepara usar a COALESCEpara padronizar o valor. Ou, se você não quiser um padrão e exigir um nome, poderá fazer algo semelhante a:

     DECLARE @UserName VARCHAR(50); -- set to the size of AuditTable.[UserWhoMadeChanges]
     SET @UserName = LEFT(RTRIM(CONVERT(VARCHAR(128), CONTEXT_INFO())), 50);
     
     IF (@UserName IS NULL)
     BEGIN
        ROLLBACK TRAN; -- cancel the DELETE operation
        RAISERROR('Please set UserName via "SET CONTEXT_INFO.." and try again.', 16 ,1);
     END;
     
     -- use @UserName in the INSERT...SELECT
     

   • CONTEXT_INFOfoi definido como um valor que não é um UserName válido e, portanto, pode exceder o tamanho do AuditTable.[UserWhoMadeChanges]campo:

     Por esse motivo, adicionei uma LEFTfunção para garantir que o que for retirado CONTEXT_INFOnão interrompa o INSERT. Conforme observado no código, você só precisa definir o 50tamanho real do UserWhoMadeChangescampo.

ATUALIZAÇÃO PARA SQL SERVER 2016 E MAIS NOVO

O SQL Server 2016 adicionou uma versão aprimorada dessa memória por sessão: Contexto da Sessão. O novo Contexto da Sessão é essencialmente uma tabela de hash de pares Valor-Chave, sendo o "Chave" do tipo sysname(ie NVARCHAR(128)) e o "Valor" SQL_VARIANT. Significado:

1. Agora existe uma separação de valores com menor probabilidade de entrar em conflito com outros usos
2. Você pode armazenar vários tipos, sem precisar se preocupar com o comportamento estranho ao recuperar o valor via CONTEXT_INFO()(para obter detalhes, consulte minha postagem: Por que CONTEXT_INFO () não retorna o valor exato definido por SET CONTEXT_INFO? )
3. Você obtém muito mais espaço: 8000 bytes no máximo por "Valor", até 256kb no total em todas as chaves (em comparação com o máximo de 128 bytes CONTEXT_INFO)

Para detalhes, consulte as seguintes páginas de documentação:

• sp_set_session_context
• SESSION_CONTEXT

Você não pode fazer isso, a menos que esteja procurando gravar o ID do usuário do servidor SQL em vez de um nível de aplicativo.

Você pode fazer uma exclusão reversível tendo uma coluna chamada DeletedBy e definindo-a conforme necessário, para que seu gatilho de atualização faça a exclusão real (ou arquive o registro, eu geralmente evito exclusões físicas sempre que possível e legal), além de atualizar sua trilha de auditoria . Para forçar exclusões a serem feitas dessa maneira, defina um on deletegatilho que gera um erro. Se você não deseja adicionar uma coluna à sua tabela física, pode definir uma exibição que inclua a coluna e defina instead ofgatilhos para manipular a atualização da tabela base, mas isso pode ser um exagero.

Existe uma maneira de passar informações para o gatilho Excluir, de modo que ele possa saber quem excluiu o registro?

Sim, aparentemente existem duas maneiras ;-). Se houver alguma reserva sobre o uso, CONTEXT_INFOcomo sugeri em minha outra resposta aqui , pensei em outra maneira que tenha uma separação funcional mais limpa de outros códigos / processos: use uma tabela temporária local.

O nome da tabela temporária deve incluir o nome da tabela que está sendo excluída, pois isso ajudará a mantê-la separada de qualquer outro código que possa ser executado na mesma sessão. Algo ao longo das linhas de:
#<TableName>DeleteAudit

Um benefício para uma tabela temporária local CONTEXT_INFOé que, se alguém em outro processo - que é de alguma forma chamado desse processo "Excluir" em particular - apenas usa incorretamente o mesmo nome da tabela temporária, o subprocesso a) cria um novo local tabela temporária do nome solicitado que será separado dessa tabela temporária inicial (mesmo que tenha o mesmo nome) eb) quaisquer instruções DML em relação à nova tabela temporária local no subprocesso não afetarão nenhum dado no tabela temporária local criada aqui no processo pai, portanto, nenhuma substituição de dados. Claro que, se um problemas de subprocesso uma declaração DML contra este nome tabela temporária sem antes emitir um CREATE TABLE do mesmo nome, então essas instruções DML irá afetar os dados nesta tabela. MAS, neste momento estamos ficando realmenteaqui, ainda mais do que com a probabilidade de sobreposição de usos CONTEXT_INFO(sim, eu sei que isso aconteceu, é por isso que digo "caso de aresta" em vez de "nunca acontecerá").

1. O aplicativo deve chamar um procedimento armazenado "Excluir" que transmita o nome de usuário (ou o que for) que está excluindo o registro. Presumo que este já seja o modelo que está sendo usado, pois parece que você já está acompanhando as operações de Inserir e Atualizar.

2. O procedimento armazenado "Excluir" faz:

   CREATE TABLE #MyTableDeleteAudit (UserName VARCHAR(50));
   INSERT INTO #MyTableDeleteAudit (UserName) VALUES (@UserName);
   
   -- DELETE STUFF HERE
   

3. O gatilho de auditoria faz:

   -- Set the datatype and length to be the same as the [UserWhoMadeChanges] field
   DECLARE @UserName VARCHAR(50);
   IF (OBJECT_ID(N'tempdb..#TriggerTestDeleteAudit') IS NOT NULL)
   BEGIN
      SELECT @UserName = UserName
      FROM #TriggerTestDeleteAudit;
   END;
   
   -- catch the following conditions: missing table, no rows in table, or empty row
   IF (@UserName IS NULL OR @UserName NOT LIKE '%[a-z]%')
   BEGIN
     /* -- uncomment if undefined UserName == badness
      ROLLBACK TRAN; -- cancel the DELETE operation
      RAISERROR('Please set UserName via #TriggerTestDeleteAudit and try again.', 16 ,1);
      RETURN; -- exit
     */
     /* -- uncomment if undefined UserName gets default value
      SET @UserName = '<unknown>';
     */
   END;
   
   INSERT INTO AuditTable (IdOfRecordedAffected, UserWhoMadeChanges) 
      SELECT del.ID, @UserName
      FROM DELETED del;
   

   Eu testei esse código em um gatilho e funciona como esperado.