Error 1305 indicates MySQL cannot find the referenced stored procedure, function, trigger, or event in the current database.
MySQL Error 1305: ER_SP_DOES_NOT_EXIST signals that the referenced stored routine or trigger is missing or named incorrectly. Verify database context, object name, and existence, then recreate or call the correct routine to resolve the error.
%s %s does not exist
MySQL throws Error 1305 when a CALL, CREATE TRIGGER, CREATE EVENT, or CREATE FUNCTION statement references a stored routine that is not present in the mysql.proc table of the active database. The server checks the object name and database schema at execution time and raises 42000 if no match is found.
Case sensitivity, dropped objects, and use of the wrong database often trigger the condition.
Replication lag or sandboxed user privileges can also hide the routine from the caller, generating the same message.
First confirm you are connected to the correct database with USE db_name;. Next query information_schema.routines or SHOW PROCEDURE STATUS to verify the routine exists. If missing, recreate it from source control or a backup.
If present, ensure the routine name in your CALL statement matches exactly, including case, and that the invoking user has EXECUTE privilege.
For replicated environments, check the replica’s Seconds_Behind_Master; a delayed apply could make the routine appear absent. If privileges block access, grant EXECUTE on the routine to the caller.
Deploy scripts often run in CI where the database default differs. Adding an explicit USE statement or qualifying the routine as schema.proc_name fixes the issue.
During blue-green releases a routine might be dropped before traffic switches; version your DDL so drop happens only after the new version is in place.
Dynamic SQL built by an application can supply incorrect parameter counts, leading developers to assume the procedure is missing. Enable general log and capture the exact statement to debug.
Store all routine definitions under version control and include idempotent CREATE OR REPLACE statements in migrations. Enforce naming conventions and case consistency.
Automate CI checks that diff expected routines against information_schema.routines before deployment.
Galaxy’s context-aware autocompletion lists only existing procedures within the selected schema, reducing typos. Endorsed queries in a Galaxy Collection ensure team members reuse verified CALL statements instead of hand-typing names.
Error 1304 (ER_PROC_NOT_ALLOWED_IN_SF_OR_TRG) occurs when a prohibited statement appears in a stored function. Unlike 1305, the routine exists but its body is invalid. Grant and privilege errors such as Error 1227 (ER_SPECIFIC_ACCESS_DENIED_ERROR) also surface during routine calls.
Fix by reviewing privilege assignments.
.
The procedure was removed in a migration or never deployed to this environment, so MySQL cannot locate it.
The session default schema differs from the routine’s schema, causing the lookup to fail.
On Unix-like systems with lower_case_table_names=0, routine names are case sensitive; mismatched casing yields Error 1305.
The routine exists on the primary but has not yet reached a replica due to lag or errors.
The routine exists but MySQL hides it from users lacking EXECUTE, leading to the same error text.
.
You can wrap the CALL in a handler that catches SQLSTATE '42000', but it is better to fix the underlying problem to avoid silent failures.
MySQL 8.0 does not support CREATE OR REPLACE for procedures. You must DROP and CREATE or use ALTER ROUTINE.
Run SHOW PROCEDURE STATUS LIKE 'name%'; or query information_schema.routines for fast lookup.
Production replicas may lag or have stricter privileges, exposing missing deployment steps that do not surface in development.
.avif)
.avif){kind=logo}
