Unlike stored procedures, event handlers do not take any arguments. You can use the EVENT_PARAMETER function to access information about the context in which an event was triggered. The information returned includes the connection ID and user ID that caused an event to be triggered, and the event name and the number of times it has been executed.

During development, you want event handlers to be triggered at convenient times. You can use the TRIGGER EVENT statement to explicitly cause an event to execute, even when the trigger condition or scheduled time has not occurred. However, TRIGGER EVENT does not cause disabled event handlers to be executed.

While it is not good practice to develop event handlers on a production database, you can disable event handlers explicitly using the ALTER EVENT statement.

It can be useful to use a single set of actions to handle multiple events. For example, you may want to take a notification action if disk space is limited on any of the devices holding the database or log files. To do this, create a stored procedure and call it in the body of each event handler, passing any needed context information as parameters to the procedure.

Debugging event handlers is very similar to debugging stored procedures. The event handlers appear in the events list.

You can use the ALTER EVENT statement with the SET HIDDEN clause to hide the definition of an event handler. Specifying the SET HIDDEN clause results in the permanent obfuscation of the event handler definition stored in the action column of the ISYSEVENT system table.

You can also determine how many instances of a particular event handler are currently active using EVENT_PARAMETER function with the NumActive context name. This function is useful to limit an event handler so that only one instance executes at any given time.

• How event handlers are executed
• ALTER EVENT statement
• EVENT_PARAMETER function [System]
• TRIGGER EVENT statement
• Debugging an event handler
• Hiding an event handler
• Triggering an event handler