Error 17630 Triggered by RETURN ERROR in Sub-Transaction Updating Indexed Fields
Error 17630 is reported after RETURN ERROR is executed in a sub-transaction that updates an indexed field in a record, if you try to update the same indexed field in that same record while in the scope of a FINALLY block.
Getting error 17630 message in FINALLY block inside a sub-transaction after RETURN ERROR or STOP
RETURN ERROR Causes Error 17630 When Indexed Field Is Re-Updated in FINALLY Block
Understanding Error 17630: Indexed Field Update Conflict in Sub-Transaction Scope
Error 17630 After RETURN ERROR and Indexed Field Update in FINALLY Block
Indexed Field Update in FINALLY Block After RETURN ERROR Leads to Error 17630

Error 17630 occurs when a RETURN ERROR is triggered in a sub-transaction that updates an indexed field, and the same field is updated again in a FINALLY block. This leads to a mismatch between the index and the record, causing the system to fail in deleting the index entry. While not a data corruption issue, it can disrupt transaction processing and is resolved in OpenEdge versions 12.2.18 and 12.8.7. A workaround involves re-fetching the record after the update to ensure consistency.

The error stems from a logical inconsistency between the set of index entries in the index and the set of records in the database. This occurs when a RETURN ERROR is triggered in a sub-transaction, leading to an attempt to delete an index entry that is missing.

Upgrade to 12.2.18, 12.8.7 or later. These versions address the error 17630 messages when changes are committed to DB, but a custom validation error is raised inside a TRANSACTION block is resolved.

Error can be avoided by adding the same line used for fetching the record after the record is last updated. This does a FIND on the buffer again, which will force to writing the current record in the buffer to the db.