In setting up an audit trail I have no problem tracking who is updating or inserting records in a table, however, tracking who deletes records seems more problematic.
I can track Inserts/Updates by including in the Insert/Update the field "UpdatedBy". This allows the INSERT/UPDATE trigger to have access to the field "UpdatedBy" via inserted.UpdatedBy
. However, with the Delete trigger no data is inserted/updated. Is there a way to pass information onto the Delete trigger such that it could know who deleted the record?
Here is an Insert/Update trigger
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
Using SQL Server 2012
Best Answer
Yes: by using a very cool (and under utilized feature) called
CONTEXT_INFO
. It is essentially session memory that exists in all scopes and is not bound by transactions. It can be used to pass info (any info--well, any that fits into the limited space) to triggers as well as back and forth between sub-proc / EXEC calls. And I have used it before for this exact same situation.Context info is a VARBINARY(128)
Set via: SET CONTEXT_INFO
Get via: CONTEXT_INFO()
Test with the following to see how it works. Notice that I am converting to
CHAR(128)
before theCONVERT(VARBINARY(128), ..
. This is to force blank-padding to make it easier to convert back toVARCHAR
when getting it out ofCONTEXT_INFO()
sinceVARBINARY(128)
is right-padded with0x00
s.Results:
PUTTING IT ALL TOGETHER:
The app should call a "Delete" stored procedure that passes in the UserName (or whatever) that is deleting the record. I assume this is already the model being used since it sounds like you are already tracking Insert and Update operations.
The "Delete" stored procedure does:
The audit trigger does:
Please note that, as @SeanGallardy pointed out in a comment, due to other procedures and/or ad hoc queries deleting records from this table, it is possible that either:
CONTEXT_INFO
has not been set and is stillNULL
:For this reason I have updated the above
INSERT INTO AuditTable
to use aCOALESCE
to default the value. Or, if you don't want a default and require a name, then you could do something similar to:CONTEXT_INFO
has been set to a value that is not a valid UserName, and hence might exceed the size of theAuditTable.[UserWhoMadeChanges]
field:For this reason I added a
LEFT
function to ensure that whatever is grabbed out ofCONTEXT_INFO
will not break theINSERT
. As noted in the code, you just need to set the50
to the actual size of theUserWhoMadeChanges
field.UPDATE FOR SQL SERVER 2016 AND NEWER
SQL Server 2016 added an improved version of this per-session memory: Session Context. The new Session Context is essentially a hash table of Key-Value pairs with the "Key" being of type
sysname
(i.e.NVARCHAR(128)
) and the "Value" beingSQL_VARIANT
. Meaning:CONTEXT_INFO()
(for details, please see my post: Why Doesn’t CONTEXT_INFO() Return the Exact Value Set by SET CONTEXT_INFO?)CONTEXT_INFO
)For details, please see the following documentation pages: