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.
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.
ERROR 1064: You have an error in your SQL syntax
How to fix "ERROR 1064: You have an error in your SQL syntax" in MySQL
ERROR 1054: Unknown column in field list
Unknown column in field list
ER_WINDOW_RANGE_FRAME_NUMERIC_TYPE (3589): RANGE frame requires numeric ORDER BY expression
RANGE frame requires numeric ORDER BY expression in MySQL window functions
CR_ALREADY_CONNECTED (2058): Handle already connected
How to fix "CR_ALREADY_CONNECTED (2058): Handle already connected" in MySQL
ER_WINDOW_DUPLICATE_NAME (3591): Duplicate window name
How to fix ER_WINDOW_DUPLICATE_NAME (3591) in MySQL window functions