Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.
Errors and warnings are handled differently. While the default action for errors is to set a value for the SQLSTATE and SQLCODE variables, and return control to the calling environment in the event of an error, the default action for warnings is to set the SQLSTATE and SQLCODE values and continue execution of the procedure.
The following demonstration procedures illustrate default handling of warnings. These demonstration procedures are based on those used in Default error handling in procedures and triggers.
In this case, the SIGNAL statement generates a
row not found condition, which is a warning rather than an error.
DROP PROCEDURE OuterProc; DROP PROCEDURE InnerProc; CREATE PROCEDURE OuterProc() BEGIN MESSAGE 'Hello from OuterProc.' TO CLIENT; CALL InnerProc(); MESSAGE 'SQLSTATE set to ', SQLSTATE,' in OuterProc.' TO CLIENT; END; CREATE PROCEDURE InnerProc() BEGIN DECLARE row_not_found EXCEPTION FOR SQLSTATE '02000'; MESSAGE 'Hello from InnerProc.' TO CLIENT; SIGNAL row_not_found; MESSAGE 'SQLSTATE set to ', SQLSTATE, ' in InnerProc.' TO CLIENT; END; CALL OuterProc();
The Interactive SQL Messages tab then displays the following:
Hello from OuterProc. Hello from InnerProc. SQLSTATE set to 02000 in InnerProc. SQLSTATE set to 00000 in OuterProc.
The procedures both continued executing after the warning was generated, with SQLSTATE set by the warning (02000).
Execution of the second MESSAGE statement in InnerProc resets the warning. Successful execution of any SQL statement resets SQLSTATE to 00000 and SQLCODE to 0. If a procedure needs to save the error status, it must do an assignment of the value immediately after execution of the statement which caused the error or warning.
|Envoyer votre avis sur cette page par email.||Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1|