The SIGNAL statement signals an error or other condition, populates the first Diagnostics Area (see Diagnostics and Condition Handling), and triggers the execution of the appropriate condition handler, if one exists. The information supplied by the SIGNAL statement is available for retrieval by the GET DIAGNOSTICS statement until the error condition is either resolved or a subsequent statement is executed.
The first Diagnostics Area is cleared and the RETURNED_SQLSTATE and/or CONDITION_IDENTIFIER are set in the first condition information area of that Diagnostics Area. Certain statement information items such as NUMBER and MORE are also filled in. Any signal information supplied is also moved to the condition information area. The most appropriate error/condition handler (if one exists) is then triggered.
If a handler executes, SQL statement execution might not continue following completion of the SIGNAL statement. The SQL statement that is executed after a SIGNAL completes is dependent upon how the handler was declared and whether that handler succeeds. For example, if a CONTINUE type handler executes and succeeds, execution continues as if no error occurred. For information about other possibilities such as UNDO and EXIT, see Diagnostics and Condition Handling.
Note: SIGNAL, RAISE ERROR, and RESIGNAL statements that execute inside handlers do not activate additional condition handling. They instead cause the handler to be exited with the signaled condition and cause the execution of the compound statement that triggered the handler to abort. In addition, the compound statement that contains the handler definition is aborted if it is different from the compound statement that triggered the handler, the same as would happen if the handler failed to resolve the triggering condition. The SIGNAL, RAISE ERROR, and RESIGNAL statements should therefore be positioned as the last statements in your condition handler.
►►─ SIGNAL ─ signal-value ─┬──────────────────────┬───────────────────────────►◄ └─ signal-information ─┘
Expansion of Where signal-value is defined as
├──┬─ condition-name ─┬────────────────────────────────────────────────────────┤ └─ sqlstate-value ─┘
Expansion of Where signal-informatiion is defined as
├── SET ─ signal-info-item-list ───────────────────────────────────────────────┤
Expansion of Where signal-info-item-list is defined as
┌─ , ────────────────┐ ├──▼─ signal-info-item ─┴──────────────────────────────────────────────────────┤
Expansion of Where signal-info-item is defined as
├── condition-info-item-name ─ = ─ proc-value-expression ──────────────────────┤
(Optional) When a signal-value is specified, existing Condition Areas within the current Diagnostics Area are pushed down in the Condition Area stack, that is, Condition Area number one becomes Condition Area number two. Condition Area number one is then populated with any supplied or implied RETURNED_SQLSTATE (supplied using sqlstate-value) and/or CONDITION_IDENTIFIER (supplied using condition-name) in addition to any other information supplied in the SET signal-information clause. The statement-information-items are modified to indicate that a SIGNAL statement was the last to modify the Diagnostics Area.
(Optional) The supplied signal-information is copied into Condition Area number one to represent the condition being signaled. The most appropriate handler, if one exists, is then triggered.
See the condition-name information in the compound statement section that begins in Compound Statement.
See the sqlstate-value information in the compound statement section that begins in Compound Statement.
The SET signal-info-item-list specification is used to set a condition-info-item such as the error message.
For information about the condition-info-item-name, including a list of the condition information items that can be set, see GET DIAGNOSTICS Statement.
For informaiton about the proc-value-expression see CASE Statement.
|
Copyright © 2014 CA.
All rights reserved.
|
|