PREPARE Statement SQL syntax for prepared statements is distinct from using prepared statement API calls. For example, you cannot use the  mysql_stmt_prepare() C API function to prepare a  PREPARE ,  EXECUTE , or DEALLOCATE PREPARE  statement. SQL syntax for prepared statements can be used within stored procedures, but not in stored functions or triggers. However, a cursor cannot be used for a dynamic statement that is prepared and executed with PREPARE  and  EXECUTE . The statement for a cursor is checked at cursor creation time, so the statement cannot be dynamic. SQL syntax for prepared statements does not support multi-statements (that is, multiple statements within a single string separated by  ;  characters). To write C programs that use the  CALL  SQL statement to execute stored procedures that contain prepared statements, the  CLIENT_MULTI_RESULTS  flag must be enabled. This is because each  CALL  returns a result to indicate the call status, in addition to any result sets that might be returned by statements executed within the procedure. CLIENT_MULTI_RESULTS  can be enabled when you call  mysql_real_connect() , either explicitly by passing the  CLIENT_MULTI_RESULTS  flag itself, or implicitly by passing  CLIENT_MULTI_STATEMENTS (which also enables  CLIENT_MULTI_RESULTS ). For additional information, see Section 13.2.1, “CALL Statement” . The  PREPARE  statement prepares a SQL statement and assigns it a name,  stmt_name , by which to refer to the statement later. The prepared statement is executed with  EXECUTE  and released with  DEALLOCATE PREPARE . For examples, see Section 13.5, “Prepared Statements” . Statement names are not case-sensitive.  preparable_stmt  is either a string literal or a user variable that contains the text of the SQL statement. The text must represent a single statement, not multiple statements. Within the statement,  ?  characters can be used as parameter markers to indicate where data values are to be bound to the query later when you execute it. The  ?  characters should not be enclosed within quotation marks, even if you intend to bind them to string values. Parameter markers can be used only where data values should appear, not for SQL keywords, identifiers, and so forth. If a prepared statement with the given name already exists, it is deallocated implicitly before the new statement is prepared. This means that if the new statement contains an error and cannot be prepared, an error is returned and no statement with the given name exists. The scope of a prepared statement is the session within which it is created, which as several implications: 13.5.1 PREPARE Statement PREPARE  stmt_name  FROM  preparable_stmt •A prepared statement created in one session is not available to other sessions. •When a session ends, whether normally or abnormally, its prepared statements no longer exist. If auto- reconnect is enabled, the client is not notified that the connection was lost. For this reason, clients may wish to disable auto-reconnect. See Automatic Reconnection Control. •A prepared statement created within a stored program continues to exist after the program finishes executing and can be executed outside the program later. •A statement prepared in stored program context cannot refer to stored procedure or function parameters or local variables because they go out of scope when the program ends and would be unavailable were the statement to be executed later outside the program. As a workaround, refer instead to user-defined variables, which also have session scope; see Section 9.4, “User-Defined Variables” . 2793