You do not need to change the statement delimiter when you write procedures. However, if you create and test procedures and triggers from some other browsing tool, you may need to change the statement delimiter from the semicolon to another character.

Each statement within the procedure ends with a semicolon. For some browsing applications to parse the CREATE PROCEDURE statement itself, you need the statement delimiter to be something other than a semicolon.

If you are using an application that requires changing the statement delimiter, a good choice is to use two semicolons as the statement delimiter (;;) or a question mark (?) if the system does not permit a multi-character delimiter.

You should end each statement within the procedure with a semicolon. Although you can leave off semicolons for the last statement in a statement list, it is good practice to use semicolons after each statement.

The CREATE PROCEDURE statement itself contains both the RESULT specification and the compound statement that forms its body. No semicolon is needed after the BEGIN or END keywords, or after the RESULT clause.

If a procedure has references to tables in it, preface the table name with the name of the owner (creator) of the table.

When a procedure refers to a table, it uses the role memberships of the procedure creator to locate tables with no explicit owner name specified. For example, if a procedure created by user_1 references Table_B and does not specify the owner of Table_B, then either Table_B must have been created by user_1 or user_1 must be a member of a role (directly or indirectly) that is the owner of Table_B. If neither condition is met, a table not found message results when the procedure is called.

You can minimize the inconvenience of long fully qualified names by using a correlation name to provide a convenient name to use for the table within a statement. For more information about correlation names, see FROM clause.

When dates and times are sent to the database from procedures, they are sent as strings. The date part of the string is interpreted according to the current setting of the date_order database option. As different connections may set this option to different values, some strings may be converted incorrectly to dates, or the database may not be able to convert the string to a date.

You should use the unambiguous date format yyyy-mm-dd or yyyy/mm/dd when using date strings within procedures. The server interprets these strings unambiguously as dates, regardless of the date_order database option setting.

One way to verify input arguments is to display the value of the parameter on the Interactive SQL Messages tab using the MESSAGE statement. For example, the following procedure simply displays the value of the input parameter var:

CREATE PROCEDURE message_test( IN var char(40) )
BEGIN
   MESSAGE var TO CLIENT;
END;

You can also use the debugger to verify that procedure input arguments were passed correctly.

• command_delimiter option [Interactive SQL]
• Date and time data types
• Lesson 2: Diagnosing the bug