Dave Mason looks at different levels of event handling within SQL Server:
While event handling for .Net developers is implemented in a unified way, this is not the case for SQL Server. Event handling for SQL Server lacks the “one stop shopping” afforded to .Net developers. *If* we had access to the code base for SQL Server and wanted to handle a specific event, we could add our own code, recompile sqlservr.exe, and be on our way. But since we don’t have this ability, we use SQL Server’s run-time hooks. Consider the following:
DDL Triggers: handles Data Definition Language events (synchronously).
Event Notifications: handles a wide swath of SQL Server events via Service Broker (asynchronously).
SQL Alerts: handles the following events:
Events with a specific error number or severity level that are written to the Windows Event Log.
Events for a specific performance condition.
WMI events.
sp_procoption: handles the startup event by specifying a stored procedure to run when the database engine service starts.
SQL Agent jobs: handles time-based events defined by user-specified job schedules (ie daily, hourly).
This sounds like the beginning of a new series.