SAPSQL_ARRAY_INSERT_DUPREC — Array Insert Duplicate Record Dump

An array insert is a single INSERT statement executed against a database table using an internal table as the source, so all rows are sent to the database in one operation instead of row by row. The database rejects the whole operation if any row's key already exists, and the open SQL layer raises CX_SY_OPEN_SQL_DB with the DUPREC subclass rather than letting the program continue with a return code. Because this is a class-based exception and most programs still rely on checking sy-subrc after INSERT, the exception goes uncaught and the runtime terminates with this dump. The message tells which table and which statement, but not why the key already existed, which is the actual investigation.

If the internal table contains duplicates in memory, fix the source program to SORT the table by the key fields and run DELETE ADJACENT DUPLICATES, or switch the build logic to COLLECT or a hashed table with unique key, before the INSERT; this requires a code change and a transport. If the cause is a rerun of a job that already wrote part of its data, do not touch the code first: check with the functional owner whether the already-inserted rows are correct, then either delete the specific already-processed keys through the proper business transaction or add a restart-safety check to the program that skips or updates existing keys, which again needs a change request. If a race condition between parallel processes is confirmed, add an ENQUEUE lock or a SELECT SINGLE FOR UPDATE style check ahead of the insert, or reschedule the jobs to run serially as an interim workaround while the code fix is built and transported. If a key generation defect is confirmed, escalate the number range logic to whoever owns that custom development; this is a design defect, not a data cleanup. If the table's key changed, treat it as a data model issue for the functional team before any code touches the program.

The reflex is to wrap the INSERT in a TRY/CATCH for CX_SY_OPEN_SQL_DB, or switch to INSERT with an implicit ignore of the duplicate error, and move on once the dump stops appearing. This silences the symptom without explaining why the duplicate existed, and it silently drops the conflicting rows from the array insert on most database platforms, meaning some records that were supposed to be posted never make it into the table. The failure resurfaces weeks later as a reconciliation gap, missing accounting documents, or missing master data that nobody connects back to this dump because the program now runs cleanly.

Make deduplication of the source internal table a mandatory review checkpoint for any program that performs an array insert, especially interface and mass-load programs: SORT plus DELETE ADJACENT DUPLICATES immediately before the statement, or build the table as a sorted or hashed type with a unique key from the start. For programs that can be rerun after failure, design them to be restart-safe by checking existing keys or using MODIFY instead of INSERT where the business logic allows an update-or-insert pattern. For concurrent key generation, use proper locking rather than relying on timing.

This is an ABAP development issue in almost every case, since the missing dedup logic, missing lock, or restart-unsafe design lives in program code. Basis involvement is limited to cases where a number range buffer or lock table sizing genuinely contributed. The handover note should state the table name and key fields involved, the program and line from the dump, whether the job is safe to simply rerun or needs data cleanup first, and whether any rows were silently lost if the program had error handling around the insert.

Closely related to ITAB_DUPLICATE_KEY, which fires for the same underlying reason but on an internal table operation rather than a database insert, and to the general DBIF_RSQL_SQL_ERROR family that covers other open SQL failures. Programs that catch this dump incorrectly often surface later as UNCAUGHT_EXCEPTION dumps elsewhere in the same interface once the swallowed error causes a follow-on inconsistency. Tables most often involved are custom Z-tables built by interface or migration programs, and standard tables extended with custom key fields.