Duplicate ECO number error when importing legacy data into ENOVIA

PLM ENOVIA
, , , , , , , ,
1

We’re migrating legacy ECO records from our old system to ENOVIA R2020x and hitting a blocking issue. The import process throws duplicate number errors even though we’ve verified the source data has unique ECO numbers. Our auto-numbering configuration appears correct in the policy settings, but the system keeps rejecting records.

Here’s the error pattern we’re seeing:


ERROR: ECO-10045 already exists
Import failed at record 156 of 2000
Constraint violation: duplicate key value

We’re using MQL scripts for the bulk import process. The legacy ECO numbers follow format ECO-NNNNN and we need to preserve these exact numbers. Has anyone dealt with preserving legacy numbering during ECO import? The data integrity is critical since these ECOs reference released parts in production.

system 2

Here’s the complete solution addressing all three focus areas:

Auto-numbering Configuration: First, modify your ECO policy to allow manual name assignment during import. Update the policy using MQL:


mod policy "ECO" state "Create"
  property "enforce" value "false";

This temporarily disables auto-numbering enforcement. After import, restore it to “true”.

Legacy Data Import Process: Your MQL import script needs to explicitly set the name and skip auto-numbering:


add bus "ECO" "ECO-10045" "-" policy "ECO" vault "Production";
mod bus "ECO" "ECO-10045" "-"
  attribute "Title" "Legacy ECO Migration";

The key is using add bus with the explicit name rather than relying on policy numbering.

MQL Scripting Best Practices: Before starting your bulk import, reset the number generator to prevent future conflicts:


mod type "ECO" property "next_number" value "20001";

Set this to one above your highest legacy ECO number (if your legacy data goes to ECO-20000). This ensures future auto-generated ECOs won’t collide with imported ones.

Critical Pre-Import Steps:

  1. Query existing ECOs to identify any number conflicts: `temp query bus “ECO” “ECO-*” “-” select name dump |;
  2. Backup your database before the import
  3. Test the import process on a small batch (50-100 records) first
  4. Verify the number generator state after test import
  5. Document the highest legacy ECO number for generator reset

Post-Import Validation: After completing the import, verify data integrity by checking that all legacy ECOs were created and the number generator is properly positioned. Run a count query to confirm the expected number of records were imported successfully.

The combination of disabling enforcement, explicit name setting in MQL, and proper generator reset should resolve your duplicate number errors while preserving legacy ECO numbers exactly as needed.

This draft is based on general ENOVIA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen this before. The issue is usually that ENOVIA’s auto-numbering generator has already created some numbers in the sequence you’re trying to import. Check if any ECOs were created manually or through testing before your migration started. Even if you later deleted them, the number generator cache might still think those numbers are taken.

4

Also verify your MQL script is using the correct import flags. When importing with existing numbers, you need to bypass the auto-numbering entirely. Are you setting the name attribute directly or relying on policy numbering? For legacy imports, you typically want to set the name explicitly and temporarily disable the auto-numbering pattern during import. After import completes, reset the number generator to start above your highest legacy number.

5

Check your policy configuration for the ECO type. The policy needs to allow manual numbering override during import. In the policy definition, verify that ‘enforce’ is set to false for the name field during the Create state. This allows your MQL script to set the name directly without triggering the auto-numbering sequence. You might need to temporarily modify the policy, run your import, then restore the original settings.

6

Another common pitfall is the number generator sequence itself. If you’re importing ECO-10045 but the generator is currently at ECO-10050 from previous activity, you’ll get conflicts when the generator wraps around. Before starting the import, query the highest existing ECO number in ENOVIA and compare it against your legacy data range. You might have overlapping ranges that need to be resolved first. Consider renumbering either the existing ENOVIA records or adjusting your legacy import numbers to avoid collision.

7

I’d also check if there are any hidden or archived ECOs with those numbers. Sometimes records exist in states that don’t show up in normal queries but still occupy the number space. Run a comprehensive MQL query to find all ECOs regardless of state before assuming the number is free. The vault might have records in obsolete or archived states that are causing the collision.

jackw 8

“Tested this on ENOVIA R2022x and temporarily setting the ECO policy enforce property to false via MQL allowed our legacy ECO numbers to import without duplicate conflicts.”

9

Don’t forget about the transaction scope either. If your MQL script is processing records in batches and a previous batch partially failed, you might have committed some numbers to the database that your script doesn’t account for in subsequent runs. Always verify the actual database state before each import batch, not just the state at the start of the full import job.

anl_pierre 10

You might have overlapping ranges that need to be resolved first.