The RESIGNAL statement is generally used within a handler to either add information to the condition information items in a Diagnostics Area that represents an error being currently handled, or to fill in subsequent Condition Areas within a Diagnostics Area to indicate that a subsequent error occurred during error handling. The most appropriate handler, if one exists, is also triggered. A RESIGNAL that specifies an SQLSTATE that has no handler can also be used to alter or customize the error information seen by the end-user.
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.
►►─ RESIGNAL ─┬────────────────┬─┬──────────────────────┬─────────────────────►◄ └─ signal-value ─┘ └─ signal-information ─┘
Expansion of Where signal-value is defined as
├──┬─ condition-name ─┬────────────────────────────────────────────────────────┤ └─ sqlstate-value ─┘
Expansion of Where signal-information 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 ─ =ssbl. ─ 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 RESIGNAL statement was the last to modify the Diagnostics Area.
(Optional) If signal-information is supplied without a signal-value, that information is copied into Condition Area number one to represent the error condition being handled. 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.
For informaiton about the proc-value-expression see CASE Statement.
|
Copyright © 2014 CA.
All rights reserved.
|
|