MESSAGE statement

Use this statement to display a message.

Syntax 
MESSAGE expression, ...
[ TYPE { INFO | ACTION | WARNING | STATUS } ]
[ TO { CONSOLE 
   | CLIENT [ FOR { CONNECTION conn-id | ALL } ] 
   | [ EVENT | SYSTEM ] LOG }
   [ DEBUG ONLY ] ]

conn-id : integer
Parameters

  • TYPE clause   This clause specifies the message type. Acceptable values are INFO, ACTION, WARNING, and STATUS. The client application must decide how to handle the message. For example, Interactive SQL displays messages in the following locations:

    • INFO   The Messages tab. INFO is the default type.

    • ACTION   A window with an OK button.

    • WARNING   A window with an OK button.

    • STATUS   The Messages tab.

  • TO clause   This clause specifies the destination of a message:

    • CONSOLE   Send messages to the database server messages window, as well as the database server message log file if one has been specified. CONSOLE is the default.

    • CLIENT   Send messages to the client application. Your application must decide how to handle the message, and you can use the TYPE as information on which to base that decision.

    • LOG   Send messages to the server log file specified by the -o option. If EVENT or SYSTEM is specified, the message is also written to the database server messages window and to the Windows event log under event source SQLANY 11.0 Admin and to the Unix Syslog under the name SQLANY 11.0 Admin (servername). Messages in the server log are identified as follows:

      • i   Messages of type INFO or STATUS.

      • w   Messages of type WARNING.

      • e   Messages of type ACTION.

  • FOR clause   For messages TO CLIENT, this clause specifies which connections receive notification about the message:

    • CONNECTION conn-id   Specify the recipient's connection ID for the message.

    • ALL   Specify that all open connections receive the message.

  • DEBUG ONLY   This clause allows you to control whether debugging messages added to stored procedures and triggers are enabled or disabled by changing the setting of the debug_messages option. When DEBUG ONLY is specified, the MESSAGE statement is executed only when the debug_messages option is set to On.

    Note

    DEBUG ONLY messages are inexpensive when the debug_messages option is set to Off, so these statements can usually be left in stored procedures on a production system. However, they should be used sparingly in locations where they would be executed frequently; otherwise, they may result in a small performance penalty.

Remarks

The MESSAGE statement displays a message, which can be any expression. Clauses can specify the message type and where the message appears.

The procedure issuing a MESSAGE ... TO CLIENT statement must be associated with a connection.

For example, the window is not displayed in the following example because the event occurs outside of a connection.

CREATE EVENT CheckIdleTime
TYPE ServerIdle
WHERE event_condition( 'IdleTime' ) > 100
HANDLER
BEGIN
   MESSAGE 'Idle engine' TYPE WARNING TO CLIENT;
END;

However, in the following example, the message is written to the database server messages window.

CREATE EVENT CheckIdleTime
TYPE ServerIdle
WHERE event_condition( 'IdleTime' ) > 100
HANDLER
BEGIN
   MESSAGE 'Idle engine' TYPE WARNING TO CONSOLE;
END;

Valid expressions can include a quoted string or other constant, variable, or function.

The FOR clause can be used to notify another application of an event detected on the database server without the need for the application to explicitly check for the event. When the FOR clause is used, recipients receive the message the next time that they execute a SQL statement. If the recipient is currently executing a SQL statement, the message is received when the statement completes. If the statement being executed is a stored procedure call, the message is received before the call is completed.

If an application requires notification within a short time after the message is sent and when the connection is not executing SQL statements, you can use a second connection. This connection can execute one or more WAITFOR DELAY statements. These statements do not consume significant resources on the server or network (as would happen with a polling approach), but permit applications to receive notification of the message shortly after it is sent.

Embedded SQL and ODBC clients receive messages via message callback functions. In each case, these functions must be registered. In embedded SQL, the message callback is registered with db_register_a_callback using the DB_CALLBACK_MESSAGE parameter. In ODBC, the message callback is registered with SQLSetConnectAttr using the ASA_REGISTER_MESSAGE_CALLBACK parameter.

Permissions

DBA authority is required to execute a MESSAGE statement containing a FOR clause or a TO EVENT LOG or TO SYSTEM LOG clause.

Side effects

None.

See also
Standards and compatibility

  • SQL/2003   Vendor extension.

Example

The following procedure displays a message on the database server messages window:

CREATE PROCEDURE message_text()
BEGIN
MESSAGE 'The current date and time: ', Now();
END;

The statement following statement displays the string The current date and time, followed by the current date and time, in the database server messages window. 

CALL message_text();
Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0