Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am having trouble getting the following procedure to run on a remote MySQL database - the given error is privilege based (#1227). Locally, the procedure runs fine.


  • Could somebody help me understand which specific part of this code raises this error, i.e. requires the said privilege?
  • Is there any way I could have corresponding functionality without a privileged call?

enter image description here

share|improve this question

migrated from Apr 8 '13 at 13:47

This question came from our site for professional and enthusiast programmers.

The INFORMATION_SCHEMA database is a "pseudo database" containing server-generated views and as far as I know, contains only read-only data. If you need to alter a variable, you need to go the standard way, see Per's answer. From the

INFORMATION_SCHEMA is the information database, the place that stores information about all the other databases that the MySQL server maintains. Inside INFORMATION_SCHEMA there are several read-only tables. They are actually views, not base tables, so there are no files associated with them.

More detailed info on GLOBAL_VARIABLES

Hope it helps..

share|improve this answer
Thanks Hiren, I do not quite see where the INFORMATION_SCHEMA DB is being manipulated here, if that is what you were implying? – chrsva Apr 8 '13 at 11:54
hmmm... by closely looking at the code, I am still confused with the line "DECLARE" AND "SET".. But this seems working on my local.. let me try again.. – Hiren Pandya Apr 8 '13 at 12:01
ok.. Now the query you have added on the first line, truncates the selected tables. but those tables are selected from the information_schema for the truncate operation, which requires SUPER privileges.. – Hiren Pandya Apr 8 '13 at 12:06

You need to examine the privileges of the connect user. The next time you connect run this:


This will tell you two things:

  1. How you you were allowed to authenticate
  2. What privileges you have with that user

Look at the beginning of the Stored Procedure definition

CREATE DEFINER = 'root'@'localhost' ...

The fact that it says DEFINER (the SQL Security) means that you assume the privileges of 'root'@'localhost' when you call the Stored Procedure. Nevertheless, there is a catch: you need the EXECUTE privilege. Why ?

According to the MySQL Documentation on Stored Procedures:

Definer and invoker security contexts differ as follows:

A stored program or view that executes in definer security context executes with the privileges of the account named by its DEFINER attribute. These privileges may be entirely different from those of the invoking user. The invoker must have appropriate privileges to reference the object (for example, EXECUTE to call a stored procedure or SELECT to select from a view), but when the object executes, the invoker's privileges are ignored and only the DEFINER account privileges matter. If this account has few privileges, the object is correspondingly limited in the operations it can perform. If the DEFINER account is highly privileged (such as a root account), the object can perform powerful operations no matter who invokes it.

A stored routine or view that executes in invoker security context can perform only operations for which the invoker has privileges. The DEFINER attribute can be specified but has no effect for objects that execute in invoker context.

Therefore, whatever you get as CURRENT_USER(), simply grant EXECUTE to that user. For example, if CURRENT_USER() is 'myuser'@'somedb', login as 'root'@'localhost' and run

GRANT EXECUTE ON *.* TO 'myuser'@'somedb';

Then, that user can run any Stored Procedure. If you want to restrict it to just the Stored Procedures in the medilife database, then do:

GRANT EXECUTE ON medilife.* TO 'myuser'@'somedb';

Give it a Try !!!

share|improve this answer

Try permitting TRUNCATE on the table to the user who is not root.

DROP, DELETE, EXECUTE are necessary.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.