21.5. Event Scheduler Limitations and Restrictions
This section lists restrictions and limitations applying to event
scheduling in MySQL.
In MySQL 5.1.6, any table referenced in an event's action
statement must be fully qualified with the name of the schema in
which it occurs (that is, as
schema_name.table_name
An event may not be created, altered, or dropped by a trigger,
stored routine, or another event. This is by design. However, an
event may create, alter, or drop triggers and stored routines.
The resolution of event schedules is measured in seconds. There is
no way to cause events scheduled to occur at the same second to
execute in a given order.
Execution of event statements have no affect on the server's
statement counts such as Com_select and
Com_insert that are displayed by SHOW
STATUS.
In MySQL 5.1.6, you may not view another user's events in the
INFORMATION_SCHEMA.EVENTS table. In other
words, any query made against this table is treated as though it
contains the condition DEFINER = CURRENT_USER()
in the WHERE clause.
Events cannot be created with a start time that is in the past.
In MySQL 5.1.6, INFORMATION_SCHEMA.EVENTS shows
NULL in the SQL_MODE column.
In MySQL 5.1.7, the SQL_MODE displayed is that
in effect when the event was created.
In MySQL 5.1.6, the only way to drop or alter an event created by
a user who is not the definer of that event is by manipulation of
the mysql.event system table by the MySQL
root user or by another user with privileges on
this table. Beginning with MySQL 5.1.7, DROP
USER drops all events for which that user was the
definer; also beginning with MySQL 5.1.7 DROP
SCHEMA drops all events associated with the dropped
schema.
As with stored routines, events are not migrated to the new schema
by the RENAME SCHEMA (or RENAME
DATABASE) statement. See
Section 13.1.9, “RENAME DATABASE Syntax”.
