誰がレコードを削除したかに関する情報を削除トリガーに渡す

監査証跡を設定する際に、テーブルのレコードを更新または挿入している人を追跡することには問題はありませんが、レコードを削除した人を追跡することはより問題が多いようです。

挿入/更新フィールドに「UpdatedBy」を含めることで、挿入/更新を追跡できます。これにより、INSERT / UPDATEトリガーはを介して "UpdatedBy"フィールドにアクセスできますinserted.UpdatedBy。ただし、削除トリガーを使用すると、データは挿入/更新されません。誰がレコードを削除したかを知ることができるように、情報を削除トリガーに渡す方法はありますか？

これは挿入/更新トリガーです

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 

SQL Server 2012の使用

誰がレコードを削除したかを知ることができるように、情報を削除トリガーに渡す方法はありますか？

はい：と呼ばれる非常に優れた（そして十分に活用されていない機能）を使用するCONTEXT_INFO。基本的に、すべてのスコープに存在し、トランザクションに拘束されないセッションメモリです。これは、情報（限られたスペースに収まるすべての情報）をトリガーに渡したり、サブプロシージャ/ EXEC呼び出しの間でやり取りしたりするために使用できます。そして、これとまったく同じ状況で以前に使用しました。

• コンテキスト情報はVARBINARY（128）です

• 設定方法：SET CONTEXT_INFO

• 取得：CONTEXT_INFO（）

次のようにテストして、動作を確認します。のCHAR(128)前にに変換していることに注意してくださいCONVERT(VARBINARY(128), ..。これは、それが簡単に戻って変換するために作るために力の空白パディングにあるVARCHARのそれを取得するときCONTEXT_INFO()以来VARBINARY(128)で右詰めである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];

結果：

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

すべてを一緒に入れて：

1. アプリは、レコードを削除するユーザー名（またはその他）を渡す「削除」ストアドプロシージャを呼び出す必要があります。挿入と更新の操作をすでに追跡しているように見えるので、これはすでに使用されているモデルだと思います。

2. 「削除」ストアード・プロシージャーは次のことを行います。

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

3. 監査トリガーは次のことを行います。

   -- 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. @SeanGallardyがコメントで指摘しているように、他の手順やアドホッククエリがこのテーブルからレコードを削除しているため、次のいずれかになる可能性があることに注意してください：

   • CONTEXT_INFO設定されておらず、まだNULLです：

     このため、デフォルト値としてINSERT INTO AuditTablea COALESCEを使用するように上記を更新しました。または、デフォルトが不要で名前が必要な場合は、次のようなことを行うことができます。

     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_INFOは有効なUserNameではない値に設定されているため、AuditTable.[UserWhoMadeChanges]フィールドのサイズを超える可能性があります。

     このため、LEFTグラブしたものがをCONTEXT_INFO壊さないようにする関数を追加しましたINSERT。コードで述べたように50、をUserWhoMadeChangesフィールドの実際のサイズに設定するだけです。

SQL Server 2016以降の更新

SQL Server 2016では、このセッションごとのメモリの改良版であるセッションコンテキストが追加されました。新しいセッションコンテキストは、本質的にはキーと値のペアのハッシュテーブルで、「キー」はタイプsysname（つまりNVARCHAR(128)）で、「値」はSQL_VARIANTです。意味：

1. 値の分離があるため、他の用途と競合する可能性が低くなります
2. さまざまなタイプを格納でき、値を取得するときに奇妙な動作を心配する必要がなくなりますCONTEXT_INFO()（詳細については、私の投稿を参照してください：CONTEXT_INFO（）がSET CONTEXT_INFOによって設定された正確な値を返さないのはなぜですか？）
3. あなたが得る多く（の最大バイト数128に比べて、すべてのキー全体で256キロバイトの合計まで、「バリュー」あたりの最大バイト8000：より多くのスペースをCONTEXT_INFO）

詳細については、次のドキュメントページをご覧ください。

• sp_set_session_context
• SESSION_CONTEXT

アプリケーションレベルではなくSQLサーバーのユーザーIDを記録する場合を除き、この方法は使用できません。

DeletedByと呼ばれる列を持ち、必要に応じて設定することにより、ソフト削除を実行できます。その後、更新トリガーは、実際の削除（またはレコードをアーカイブします。通常、ハード削除は可能な限り合法です）および監査証跡を更新します。 。この方法で削除を強制on deleteするには、エラーを発生させるトリガーを定義します。物理テーブルに列を追加したくない場合は、列を追加するビューを定義しinstead of、基本テーブルの更新を処理するトリガーを定義できますが、それはやり過ぎかもしれません。

誰がレコードを削除したかを知ることができるように、情報を削除トリガーに渡す方法はありますか？

はい、明らかに2つの方法があります;-)。ここの他の回答でCONTEXT_INFO提案したように使用について予約がある場合、他のコード/プロセスからより明確に機能的に分離できる別の方法を考えました：ローカル一時テーブルを使用します。

一時テーブル名には、同じセッションで実行される可能性のある他のコードと区別するのに役立つため、削除されるテーブル名を含める必要があります。以下の線に沿った何か：
#<TableName>DeleteAudit

ローカル一時テーブルに対する1つの利点CONTEXT_INFOは、別のプロシージャの誰か（つまり、この特定の「削除」プロシージャから何らかの方法で呼び出された場合）が偶然同じ一時テーブル名を誤って使用した場合、サブプロセスはa）新しいローカルを作成することです。この最初の一時テーブルとは異なる（同じ名前であっても）要求された名前の一時テーブル、およびb）サブプロセスの新しいローカル一時テーブルに対するDMLステートメントは、ここで親プロセス内に作成されたローカル一時テーブル。データの上書きはありません。もちろん、最初に同じ名前のCREATE TABLEを発行せずにサブプロセスがこの一時テーブル名に対してDMLステートメントを発行する場合、それらのDMLステートメントはこのテーブルのデータに影響を与えます。しかし、この時点で私たちは本当にここでのCONTEXT_INFOエッジケースは、使用の重複の可能性よりもさらにそうです（そうです、それが起こったことを知っています、それが私が「決して起こらない」ではなく「エッジケース」と言う理由です）。

1. アプリは、レコードを削除するユーザー名（またはその他）を渡す「削除」ストアドプロシージャを呼び出す必要があります。挿入と更新の操作をすでに追跡しているように見えるので、これはすでに使用されているモデルだと思います。

2. 「削除」ストアード・プロシージャーは次のことを行います。

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

3. 監査トリガーは次のことを行います。

   -- 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;

   このコードをトリガーでテストしましたが、期待どおりに動作します。