After migrating 5,000+ change orders from our legacy PLM system to Agile 9.3.4, the auto-numbering sequence is generating duplicate ECO numbers. The migration imported ECOs with numbers ECO-00001 through ECO-05234, but when users create new ECOs, the system assigns numbers that overlap with migrated data (starting from ECO-00001 again).
Our auto-numbering configuration in Admin Console shows:
Sequence: ECO_SEQ
Prefix: ECO-
Next Number: 00001
Increment: 1
The legacy data migration didn’t update the sequence counter, so Agile doesn’t know about the existing numbers. Now we’re getting “Duplicate number” errors when the sequence reaches numbers already used by migrated ECOs. We need to reset the sequence to start after ECO-05234 and prevent any future duplicates. What’s the proper way to synchronize the auto-numbering sequence with migrated data?
Yes, you’ll need to temporarily disable the auto-numbering for ECO class, update the sequence, then re-enable it. But there’s a better approach for post-migration scenarios - use a PX extension to query the max existing number and auto-adjust the sequence on first use. This handles edge cases where migration happens in batches.
Be careful with direct database updates - they can cause sequence corruption if not done properly. There’s usually an Admin Console function to reset sequences. Look under Admin → Auto-Numbering → Sequences and see if there’s a “Set Next Number” option. This is safer than SQL updates because it validates the new value against existing records.
The direct SQL approach works but you need to be precise. The sequence table name varies by Agile version. In 9.3.4, it’s typically NODETABLE where CLASS_NAME=‘ECO’ and field NEXT_AUTO_NUMBER holds the counter. Query the current max ECO number from your migrated data, add a buffer (like 100), and update NEXT_AUTO_NUMBER to that value. Don’t forget to commit and clear the application cache afterward.