If you’re in an enterprise environment some form of auditing is likely to be required so you can track who inserted, updated or deleted what in your database. Using triggers to insert into audit tables is usually a good fit for this, particularly if your database can be updated from multiple sources.
Within both insert and update triggers you have access to the original record inserted or updated from your web app so you can access the updated_by column from the original record and pop this into your audit_* tables. In the case of deletes however, there never is any user information passed to the delete statement so delete triggers don’t know who specifically (the DB connection itself is usually shared) issued the delete. Using a session like feature in SQL Server 2000+ called CONTEXT_INFO however we can ‘pass’ the specific id of the user issuing the delete from our web app to the trigger.
Passing user info to delete trigger using CONTEXT_INFO
CONTEXT_INFO allows us to associate a limited (very limited but enough space for user info) amount of information with the current SQL Server connection. This info can then be read back at any stage from within the same connection. Using this to pass user info to a trigger is quite easy then:
- Set CONTEXT_INFO to userID logged into your web app
- Issue delete statement from your web app
- Read CONTEXT_INFO back in the delete trigger
As long as all three above happen in the same connection this should work fine. Setting the context is easy, but is best done from within a store procedure to encapsulate the code to deal with CONTEXT_INFO (cumbersome binary). SetUserContext below takes the user id as a param and stores it into CONTEXT_INFO.
CREATE PROCEDURE [dbo].[SetUserContext]
@userId NVARCHAR (30)
SET NOCOUNT ON;
DECLARE @context VARBINARY(128)
SET @context = CONVERT(VARBINARY(128), @userId)
SET CONTEXT_INFO @context
Reading CONTEXT_INFO is best done through a function so you can just directly call it from your delete trigger statement that inserts into your audit_* tables. The GetUserContext function below returns CONTEXT_INFO if it is set or the standard suser_name() if it is not set.
Checking for null and falling back on the connected DB user is important if a DB can be updated directly by an admin or support person outside the context of an app which would set CONTEXT_INFO.
CREATE FUNCTION [dbo].[GetUserContext] ()
RETURNS NVARCHAR (30)
DECLARE @idToReturn NVARCHAR(30)
IF CONTEXT_INFO() IS NOT NULL
SELECT @IdToReturn = CONVERT(NVARCHAR (30), CONTEXT_INFO())
SELECT @IdToReturn = suser_name()
And finally a sample delete trigger which calls the function is below:
CREATE TRIGGER manager_d
FROM deleted AS d
After you have created the sproc for setting the context, the function for reading the context and have a couple of delete audit triggers created that’s things from the database point of view set up.
Setting CONTEXT_INFO using entity framework
In your web app you only care about setting the context. This can be done by simply calling the procedure. In entity framework this is easy:
public virtual void SetUserContext(string userId)
var idParam = new SqlParameter("@userId", userId);
this.Database.ExecuteSqlCommand("SetUserContext @userId", idParam);
Then in an overload of the SaveChanges method you simple call the SetUserContext sproc before you call the base SaveChanges method:
public void SaveChanges(string userId)
using (var scope = Database.BeginTransaction())
Both the above functions would go in your database context class (the one which derives from DbContext).
Due to the fact that when executing stored procedures entity framework opens a connection, executes the proc and then immediately closes the connection, the context_info will be lost by the time we call SaveChanges which is when the delete trigger will run. To ensure both the setting and the reading of the context takes places in the same connection, we need to wrap them both in the same transaction as can be seen above.
What about connection pooling?
When a connection is being reused .Net SQL Server client executes the sp_reset_connection stored procedure which resets most connection specific state such as temp tables, cursors, transactions and crucially from the point of view of this article, CONTEXT_INFO. This is the case since SQL Server 2005 and above.
This means if you’re using connection pooling, which you really should be, you will not run into state sharing issues and thus connection pooling does not preclude you from using CONTEXT_INFO as part of your auditing solution. SQL Server 2000 users… get with the times or just reset CONTEXT_INFO after you issue your delete.
I hope you find the above useful. Please let me know your thoughts or questions below.
List of what gets reset when a connection is reused from the connection pool
Stack Overflow question from a user who is concerned about creating race conditions if using CONTEXT_INFO
Another article about using CONTEXT_INFO from within Entity framework
Article about SESSION_CONTEXT which is a new and improved session mechanism in SQL Server 2016 which overcomes a lot of the limitations associated with CONTEXT_INFO