Solving PLS-00410: Duplicate Fields in RECORD, TABLE, or Argument List Are Not Allowed

The PL/SQL error PLS-00410 is encountered when the compiler finds duplicate identifiers in a RECORD, TABLE, or subprogram argument list. Since PL/SQL does not allow two fields or parameters to share the same name within the same scope or structure, this error flags such issues.

This article will explain the causes of this error, demonstrate examples that produce it, and show how to fix the problem effectively.

Error Message Explained

PLS-00410:

Duplicate fields in RECORD, TABLE, or argument list are not allowed

What it means:

This error occurs when two or more identifiers (field names or parameters) have the same name in a RECORD, TABLE, or subprogram definition.

Common Scenarios That Trigger PLS-00410

1. Duplicate Fields in RECORD

Example (Incorrect):

DECLARE
   TYPE employee_rec IS RECORD (
      emp_id NUMBER,
      emp_name VARCHAR2(100),
      emp_id NUMBER  -- ❌ Duplicate field name
   );
BEGIN
   NULL;
END;
/

Error:

PLS-00410: duplicate fields in RECORD, TABLE or argument list are not allowed

Fix:

Change one of the field names to be unique.

DECLARE
   TYPE employee_rec IS RECORD (
      emp_id NUMBER,
      emp_name VARCHAR2(100),
      emp_dept_id NUMBER  -- ✅ Unique field name
   );
BEGIN
   NULL;
END;
/

2. Duplicate Parameters in a Procedure or Function

Example (Incorrect):

CREATE OR REPLACE PROCEDURE update_salary (
   emp_id NUMBER,
   emp_id NUMBER  -- ❌ Duplicate parameter
)
IS
BEGIN
   NULL;
END;
/

Error:

PLS-00410: duplicate fields in RECORD, TABLE or argument list are not allowed

Fix:

Rename one of the parameters:

CREATE OR REPLACE PROCEDURE update_salary (
   p_emp_id NUMBER,
   p_new_salary NUMBER
)
IS
BEGIN
   DBMS_OUTPUT.PUT_LINE('Updating employee ' || p_emp_id || ' salary to ' || p_new_salary);
END;
/

3. Duplicate Fields in a TABLE Type

Just like RECORD, if you define a PL/SQL TABLE type or VARRAY with duplicate fields, the error will be raised.

However, note that TABLE and VARRAY structures do not allow multiple fields. The confusion often arises when people try to define composite types improperly.

Special Note: Shadowing Doesn’t Apply

PL/SQL does not allow field shadowing inside composite types. Even if you’re used to shadowing variable names in nested blocks, that doesn’t apply to parameter lists or RECORD definitions. Every field must be uniquely named.

Best Practices to Avoid PLS-00410

• Use prefixes like p_ for parameters, v_ for variables, r_ for records to avoid naming collisions.
• Avoid copy-pasting without checking for duplicate names in parameter lists or record structures.
• Use meaningful field names to distinguish attributes (e.g., emp_id, dept_id, mgr_id).

Example: Correct Use in RECORD and Procedure

DECLARE
   TYPE employee_rec IS RECORD (
      emp_id     NUMBER,
      emp_name   VARCHAR2(100),
      dept_id    NUMBER
   );

   r_emp employee_rec;

   PROCEDURE print_employee(p_emp_id NUMBER, p_emp_name VARCHAR2) IS
   BEGIN
      DBMS_OUTPUT.PUT_LINE('ID: ' || p_emp_id || ', Name: ' || p_emp_name);
   END;

BEGIN
   r_emp.emp_id := 101;
   r_emp.emp_name := 'Alice';
   r_emp.dept_id := 10;

   print_employee(r_emp.emp_id, r_emp.emp_name);
END;
/

Summary Table

Conclusion

The PLS-00410 error is a clear indicator of poor naming or a copy-paste mistake in field or parameter lists. It’s simple to fix by renaming the duplicate identifiers to make each one distinct and meaningful. Keeping your naming conventions consistent and readable helps avoid such conflicts and improves maintainability.