Event Scheduler Restrictions procedures are written to the binary log, even for statement-based binary logging. See Section 25.7, “Stored Program Binary Logging” . Event Scheduler Restrictions The following limitations are specific to the Event Scheduler: •Event names are handled in case-insensitive fashion. For example, you cannot have two events in the same database with the names  anEvent  and  AnEvent . •An event may not be created, altered, or dropped from within a stored program, if the event name is specified by means of a variable. An event also may not create, alter, or drop stored routines or triggers. •DDL statements on events are prohibited while a  LOCK TABLES  statement is in effect. •Event timings using the intervals  YEAR ,  QUARTER ,  MONTH , and  YEAR_MONTH  are resolved in months; those using any other interval are resolved in seconds. There is no way to cause events scheduled to occur at the same second to execute in a given order. In addition—due to rounding, the nature of threaded applications, and the fact that a nonzero length of time is required to create events and to signal their execution—events may be delayed by as much as 1 or 2 seconds. However, the time shown in the  INFORMATION_SCHEMA.EVENTS  table’s  LAST_EXECUTED  column is always accurate to within one second of the actual event execution time. (See also Bug #16522.) •Each execution of the statements contained in the body of an event takes place in a new connection; thus, these statements have no effect in a given user session on the server’s statement counts such as  Com_select  and  Com_insert  that are displayed by  SHOW STATUS . However, such counts  are updated in the global scope. (Bug #16422) •Events do not support times later than the end of the Unix Epoch; this is approximately the beginning of the year 2038. Such dates are specifically not permitted by the Event Scheduler. (Bug #16396) •References to stored functions, loadable functions, and tables in the  ON SCHEDULE  clauses of  CREATE EVENT  and  ALTER EVENT  statements are not supported. These sorts of references are not permitted. (See Bug #22830 for more information.) Stored routines and triggers in NDB Cluster While stored procedures, stored functions, triggers, and scheduled events are all supported by tables using the  NDB  storage engine, you must keep in mind that these do  not  propagate automatically between MySQL Servers acting as Cluster SQL nodes. This is because stored routine and trigger definitions are stored in tables in the  mysql  system database using  InnoDB  tables, which are not copied between Cluster nodes. Any stored routine or trigger that interacts with MySQL Cluster tables must be re-created by running the appropriate  CREATE PROCEDURE ,  CREATE FUNCTION , or  CREATE TRIGGER  statements on each MySQL Server that participates in the cluster where you wish to use the stored routine or trigger. Similarly, any changes to existing stored routines or triggers must be carried out explicitly on all Cluster SQL nodes, using the appropriate  ALTER  or  DROP  statements on each MySQL Server accessing the cluster. Warning Do  not  attempt to work around the issue just described by converting any  mysql database tables to use the  NDB  storage engine.  Altering the system tables in the mysql  database is not supported  and is very likely to produce undesirable results. 25.9 Restrictions on Views 4764