## 25.8 Restrictions on Stored Programs 

•SQL Statements Not Permitted in Stored Routines 

•Restrictions for Stored Functions 

•Restrictions for Triggers 

•Name Conflicts within Stored Routines 

•Replication Considerations 

•Debugging Considerations 

•Unsupported Syntax from the SQL:2003 Standard 

•Stored Routine Concurrency Considerations 

•Event Scheduler Restrictions 

•Stored routines and triggers in NDB Cluster 

These restrictions apply to the features described in Chapter 25, Stored Objects . 

Some of the restrictions noted here apply to all stored routines; that is, both to stored procedures and stored functions. There are also some restrictions specific to stored functions but not to stored procedures. 

The restrictions for stored functions also apply to triggers. There are also some restrictions specific to triggers. 

The restrictions for stored procedures also apply to the DO  clause of Event Scheduler event definitions. There are also some restrictions specific to events. 

## SQL Statements Not Permitted in Stored Routines 

Stored routines cannot contain arbitrary SQL statements. The following statements are not permitted: 

•The locking statements LOCK TABLES  and UNLOCK TABLES . 

• ALTER VIEW . 

• LOAD DATA . 

•SQL prepared statements ( PREPARE , EXECUTE , DEALLOCATE PREPARE ) can be used in stored procedures, but not stored functions or triggers. Thus, stored functions and triggers cannot use dynamic SQL (where you construct statements as strings and then execute them). 

•Generally, statements not permitted in SQL prepared statements are also not permitted in stored programs. For a list of statements supported as prepared statements, see Section 13.5, “Prepared Statements” . Exceptions are SIGNAL , RESIGNAL , and GET DIAGNOSTICS , which are not permissible as prepared statements but are permitted in stored programs. 

•Because local variables are in scope only during stored program execution, references to them are not permitted in prepared statements created within a stored program. Prepared statement scope is the current session, not the stored program, so the statement could be executed after the program ends, at which point the variables would no longer be in scope. For example, SELECT ... INTO local_var cannot be used as a prepared statement. This restriction also applies to stored procedure and function parameters. See Section 13.5.1, “PREPARE Statement” . 

