<p>The server cannot find a corresponding GRANT statement for the specified user on the requested stored routine.</p>
<p>MySQL Error 1403: ER_NONEXISTING_PROC_GRANT appears when a user tries to execute, alter, or drop a stored procedure or function without an existing EXECUTE privilege on that routine. Re-grant the proper privilege with GRANT EXECUTE ON PROCEDURE db.routine TO 'user'@'host' to resolve.</p>
There is no such grant defined for user '%s' on host '%s'
The error message There is no such grant defined for user '%s' on host '%s' on routine '%s' means MySQL searched the mysql.proc_priv or mysql.routines table and did not find a privilege row that matches the current user and the referenced stored procedure or function.
MySQL raises the 42000 SQLSTATE when a privilege check fails at runtime. The server blocks the statement to protect routine security and ownership integrity.
This error occurs when a user lacks EXECUTE, ALTER ROUTINE, or DROP ROUTINE privileges on the target routine. It often surfaces after restoring a dump, renaming a routine, or copying data between servers without replicating routine-level grants.
Another trigger is executing a DEFINER-based routine after the definer account was removed or its host specification changed. MySQL still checks the original definer privileges.
Connect as a user with the global SUPER or the specific routine owner rights. Issue a GRANT EXECUTE (and ALTER or DROP if needed) on the routine to the affected account. Flush privileges if you manipulate system tables directly.
Confirm the grant with SHOW GRANTS FOR 'user'@'host';. Retest the procedure call to verify the error is gone.
After a dump-and-restore, routine privileges might be missing because mysqldump does not export them unless you add --routines --triggers --events and --flush-privileges. Regenerate the grants or re-export with those flags.
If you cloned a database under a new name, existing routine grants still reference the old schema. Recreate or ALTER DEFINER, then GRANT EXECUTE on the new_db.proc to users.
Always back up the mysql database or use mysqldump --routines to capture privilege metadata. Automate privilege provisioning in deployment scripts to maintain parity across environments.
Use Galaxy collections to store GRANT statements alongside routine definitions so teams can reapply them consistently in staging, prod, and local setups.
The user attempts to CALL or SELECT FROM a routine without EXECUTE permission on that specific procedure or function.
mysqldump or other backup tools restored routine code but not its associated privilege rows, leaving users without the needed rights.
The routine was created with DEFINER='old_user'@'%', but the definer account or its privileges no longer exists, so privilege resolution fails.
Renaming or copying a database changes the routine schema name, invalidating previously scoped routine privileges.
Raised when a user lacks privileges on a specific table, similar in nature but scoped to tables.
Occurs when a user is blocked from executing a routine due to insufficient privileges, but the grant row exists with inadequate rights.
Triggered when issuing a REVOKE for a grant that does not exist, often paired with routine privilege maintenance.
No. You must grant EXECUTE on *.* or each routine individually. Database-level grants do not apply to routines.
No. The only safe solution is to grant the missing privilege or run the statement as a more privileged user.
MySQL 8 enforces definer and privilege checks more strictly. Grants that worked in 5.7 may need to be reapplied.
Galaxy stores and versions GRANT scripts in Collections, making it easy to re-run them after schema changes or database migrations.
.avif)
.avif){kind=logo}
