Is it possible to definitively identify whether a DML command was issued from a stored procedure?

I have inherited a SQL Server 2008 database to which calling applications have access through stored procedures.

Each table in the database has a shadow audit table into which Insert/Update/Delete operations for are logged.

Performance testing on populating the audit tables showed that inserting the audit records using OUTPUT clauses was 20% or so faster than using t开发者_StackOverflow社区riggers, so this has been implemented in the stored procedures.

However, because this design cannot track changes made directly to the tables through DML statements issued directly against the tables, triggers have also been implemented which use the value of @@NESTLEVEL to determine whether or not to run the trigger (the assumption being that all DML run through stored procedures will have @@NESTLEVEL > 1). i.e. the body of the trigger code looks something like:

IF  @@NESTLEVEL =   1   -- implies call is direct sql so generate history from here
    BEGIN
... insert into audit table

This design is flawed because it won't track updates where DML statements are executed in dynamic SQL, or any other context where @@NESTLEVEL is raised above 1.

Can anyone suggest a completely reliable method we can use in the triggers to execute them only if not triggered by a stored procedure?

Or is this (as I suspect) not possible?

Use CONTEXT_INFO (Transact-SQL). In the procedure set a value to alert the trigger to not record anything:

--in the procedure doing the insert/update/delete

DECLARE @CONTEXT_INFO  varbinary(128)
SET @CONTEXT_INFO =cast('SkipTrigger=Y'+REPLICATE(' ',128) as varbinary(128))
SET CONTEXT_INFO @CONTEXT_INFO

--do insert/update/delete that will fire the trigger

SET CONTEXT_INFO 0x0 

In the trigger check CONTEXT_INFO and determine if you need to do anything:

--here is the portion of the trigger to retrieve the value:

IF CAST(CONTEXT_INFO() AS VARCHAR(128))='SkipTrigger=Y'
BEGIN
    --log your data here
END

for anyone just doing a rogue insert/update/delete they will not have set the CONTEXT_INFO and the trigger will record the change. You could get fancy with the value you put into CONTEXT_INFO, like the table name or @@SPID, etc. if you think the rogue code will attempt to use CONTEXT_INFO as well.

I don't think so. There is a longstanding Connect item to get access to the call stack