Error 1302 occurs when a stored procedure or function has duplicate variable declarations or a local variable conflicts with a parameter name. Rename one of the conflicting identifiers to resolve the issue.
Fixes 1302
ERROR 1302: Conflicting declarations: 'name1' and 'name2'ERROR 1302: Conflicting declarations: 'name1' and 'name2'ERROR 1302: Conflicting declarations
On this page
MySQL Error 1302 (ER_CONFLICTING_DECLARATIONS) indicates that your stored procedure, function, or trigger contains conflicting or duplicate declarations. This typically happens when you declare a local variable with the same name as a procedure parameter, or when you declare the same variable twice in different scopes. MySQL enforces strict naming to prevent ambiguity in variable scope resolution, so it rejects any SQL code with conflicting declarations to ensure your procedures execute predictably.
Look at your error message carefully. The full error includes the conflicting names:
ERROR 1302: Conflicting declarations: 'name1' and 'name2'The error message will show you exactly which two identifiers are conflicting. This is your starting point for fixing the issue.
Check the parameters defined in your CREATE PROCEDURE or CREATE FUNCTION statement. List all parameter names:
CREATE PROCEDURE my_proc(
IN param1 VARCHAR(100),
IN param2 INT,
OUT result VARCHAR(255)
)Note down all parameter names so you can compare them against local variables.
Within the BEGIN...END block of your procedure, find all DECLARE statements:
BEGIN
DECLARE param1 VARCHAR(50); -- PROBLEM: conflicts with input parameter
DECLARE myVar INT;
-- procedure code here
ENDLook for any DECLARE statements that use the same name as a parameter or another DECLARE in the same block.
Choose one of the conflicting names and rename it to be unique. Typically, rename the local variable (DECLARE) rather than the parameter:
CREATE PROCEDURE my_proc(
IN param1 VARCHAR(100),
IN param2 INT,
OUT result VARCHAR(255)
)
BEGIN
DECLARE param1_temp VARCHAR(50); -- Renamed from param1
DECLARE myVar INT;
SET param1_temp = param1; -- Use the renamed variable
-- rest of procedure
ENDUpdate all references to use the new variable name throughout the procedure.
Adopt a naming convention to prevent future conflicts. For example, prefix local variables:
CREATE PROCEDURE process_user(
IN userId INT,
IN userName VARCHAR(100)
)
BEGIN
DECLARE v_tempId INT;
DECLARE v_tempName VARCHAR(100);
DECLARE v_result VARCHAR(255);
-- Use v_ prefix for all local variables
ENDCommon conventions include prefixes like v_ (variable), l_ (local), or suffixes like _temp or _var.
After renaming, drop and recreate the procedure:
DROP PROCEDURE IF EXISTS my_proc;
CREATE PROCEDURE my_proc(
IN param1 VARCHAR(100),
IN param2 INT,
OUT result VARCHAR(255)
)
BEGIN
DECLARE param1_temp VARCHAR(50);
-- ... rest of code
END;Then call it to verify it works:
CALL my_proc('test', 123, @result);
SELECT @result;MySQL applies strict scoping rules for variables in stored procedures. Local variables in inner BEGIN...END blocks take precedence over parameters, which take precedence over table columns. This design prevents unexpected behavior, but means you cannot have name conflicts at any level. In some MySQL versions or with certain storage engines, character set and collation declarations can also trigger this error if incompatible specifications are used in the same statement. When migrating procedures from other databases (Oracle, SQL Server), be aware that their scoping rules may differ, so you may need to rename variables during migration.