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 Sybase IQ 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]” in Chapter 5, “SQL Functions,” in the Sybase IQ Reference Manual.

Actions of event handlers

When a trigger condition is satisfied and an event handler executes, one or more actions are carried out, as defined in the CREATE EVENT statement. These actions vary and can include sending an e-mail message, performing a backup, or writing to a file.

Sybase IQ now supports the use of the system extended stored procedures. Microsoft Messaging API (MAPI) stored procedures, such as xp_sendmail, are supported only on Windows. The other system extended stored procedures, such as xp_cmdshell, xp_read_file, and xp_write_file, are supported on both Windows and UNIX platforms. On UNIX, an event handler can send an e-mail message by calling sendmail() from xp_cmdshell().

For details on the use of the system extended stored procedures, see the chapter “System Procedures and Functions” in the Adaptive Server Anywhere Reference manual. Information on how to access this manual is provided in the Release Bulletin for your platform.

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” in Chapter 6, “SQL Statements,” in the Sybase IQ Reference Manual.

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.

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.

For step-by-step instructions, see “Debugging an event handler”.

For an example on using event handling, see “Managing IQ user accounts and connections”.