Contents Index Understanding event handlers Schedule and event internals

ASA Database Administration Guide
  Automating Tasks Using Schedules and Events
    Understanding event handlers

Developing event handlers


Event handlers, whether for scheduled events or for system event handling, contain compound statements, and are similar in many ways to stored procedures. You can add loops, conditional execution, and so on, and you can use the Adaptive Server Anywhere debugger to debug event handlers.

Context information for event handlers 

One difference between event handlers and stored procedures is that event handlers do not take any arguments. Certain information about the context in which an event was triggered is available through the event_parameter function, which supplies information about the connection that caused an event to be triggered (connection ID, user ID), as well as the event name and the number of times it has been executed.

For more information, see EVENT_PARAMETER function [System].

Testing event handlers 

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.

For more information, see TRIGGER EVENT statement.

While it is not good practice to develop event handlers on a production database, you can disable event handlers from Sybase Central or 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.

Debugging event handlers 

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

One difference is that, because each event handler runs on its own connection, you must be sure to select All connections before setting a breakpoint in an event handler.

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

For more information about the NumActive event parameter, see EVENT_PARAMETER function [System].

For more information about step-by-step instructions, see Debugging an event handler.


Contents Index Understanding event handlers Schedule and event internals