Implementation of Multi-Event Triggers in SQL Server with Audit Logging

Dec 05, 2025 · Programming · 12 views · 7.8

Keywords: SQL Server | Trigger | Audit | INSERT | UPDATE | DELETE

Abstract: This article, based on a real Q&A, details the method to create a comprehensive trigger in SQL Server that handles INSERT, UPDATE, and DELETE operations. By analyzing error syntax examples, it presents the correct implementation and explains how to use inserted and deleted tables for audit logging. The article aims to help developers understand the core concepts and best practices of triggers.

Introduction

In database management systems, triggers are powerful tools for automatically executing specific actions upon data modifications. This article addresses a common issue where users attempt to create an all-in-one trigger but encounter syntax errors, such as multiple AFTER statements causing parsing failures.

Error Syntax Analysis

The user's code example demonstrates incorrect trigger structure:

CREATE TRIGGER trig_all_dml
 ON [dbo.file]
 AFTER UPDATE
 AS BEGIN
    UPDATE 
           (excess code)       
 END

 AFTER INSERT
 AS BEGIN
     UPDATE 
             (excess code)
  END

 AFTER DELETE
 AS BEGIN
    UPDATE (excess code)

  END
  GO

The main issue is improper syntax: SQL Server requires trigger events (e.g., UPDATE, INSERT, DELETE) to be listed in a single AFTER clause, not repeated separately. This causes the parser to error at the second AFTER.

Correct Trigger Implementation

Based on the best answer, here is the corrected trigger code, applicable to SQL Server 2008 and later:

create trigger Employee_trigger
on Employees
after UPDATE, INSERT, DELETE
as
declare @EmpID int,@user varchar(20), @activity varchar(20);
if exists(SELECT * from inserted) and exists (SELECT * from deleted)
begin
    SET @activity = 'UPDATE';
    SET @user = SYSTEM_USER;
    SELECT @EmpID = EmployeeID from inserted i;
    INSERT into Emp_Audit(EmpID,Activity, DoneBy) values (@EmpID,@activity,@user);
end

If exists (Select * from inserted) and not exists(Select * from deleted)
begin
    SET @activity = 'INSERT';
    SET @user = SYSTEM_USER;
    SELECT @EmpID = EmployeeID from inserted i;
    INSERT into Emp_Audit(EmpID,Activity, DoneBy) values(@EmpID,@activity,@user);
end

If exists(select * from deleted) and not exists(Select * from inserted)
begin 
    SET @activity = 'DELETE';
    SET @user = SYSTEM_USER;
    SELECT @EmpID = EmployeeID from deleted i;
    INSERT into Emp_Audit(EmpID,Activity, DoneBy) values(@EmpID,@activity,@user);
end

This trigger is defined on the Employees table, handling UPDATE, INSERT, and DELETE events, and logs operations to the Emp_Audit audit table.

Code Explanation

The trigger operates based on the inserted and deleted tables: the inserted table holds new data for INSERT or UPDATE operations, and the deleted table holds old data for DELETE or UPDATE operations. By checking the existence of these tables, the operation type can be determined:

In the code, the SYSTEM_USER function retrieves the current user, and relevant information is inserted into the audit table. The audit table Emp_Audit should be pre-created with fields such as EmpID, Activity, DoneBy, and Date_Time, where Date_Time defaults to GETDATE().

Additional Notes and Best Practices

While this trigger implements basic audit functionality, performance considerations are crucial in real-world applications: triggers can impact the efficiency of data modification operations, especially in high-concurrency scenarios. Recommendations include:

From other answers, it can be supplemented that triggers can also be used for more advanced purposes, such as data validation or cascading updates, but careful design is needed to avoid recursive triggering.

Conclusion

This article has covered the correct syntax and methods for creating multi-event triggers in SQL Server, with a focus on audit logging implementation. Key takeaways include trigger event definition, use of inserted and deleted tables, and correction of common syntax errors. This knowledge aids developers in building more robust and maintainable database systems.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.