SAPSQL_EMPTY_IN_LIST — SAPSQL_EMPTY_IN_LIST runtime error explained

SAPSQL_EMPTY_IN_LIST is the runtime error behind exception class CX_SY_OPEN_SQL_DB, raised by the database interface when it encounters an IN or NOT IN condition referencing a selection table or range table with no entries, in a statement variant where the kernel cannot resolve the condition into valid native SQL at the point the statement is parsed. When the IN condition is static and known at compile time, an empty table is normally optimized away quietly - a plain IN against an empty table just returns no rows, no dump. The problem appears when the WHERE clause is assembled dynamically, for example through string concatenation into a dynamic WHERE table, through generated CDS access, or through negated conditions where the semantics of an empty exclusion list are ambiguous. Because the exception class is catchable, the dump only appears when nobody in the call stack has a TRY/CATCH around the statement.

If the cause is a dynamically built WHERE clause with an empty range, add an IS INITIAL check before the fragment is appended to the dynamic WHERE table and skip the fragment entirely when the range has no entries; this is a code change requiring a transport. If the cause is a NOT IN against a potentially empty table, replace the negated dynamic condition with explicit logic that tests IS INITIAL first and either omits the exclusion or constructs the positive equivalent, again a code fix under a change request. If the cause sits in a CDS view or AMDP parameter, validate the parameter table before it reaches the generated SQL layer, in the calling ABAP code rather than inside the CDS definition where validation options are limited. If the cause is an interface sending an empty range where a populated one was assumed, fix the receiving program's defensive check rather than forcing the sender to always populate it, since other callers may legitimately send empty tables. None of these are basis-side or configuration fixes; all require an ABAP change and a transport.

The reflex fix is wrapping the offending SELECT in TRY/CATCH INTO cx_sy_open_sql_db and returning an empty internal table on catch, without asking why the range was empty in the first place. This stops the dump but silently changes program behavior: for a positive IN it happens to match the intended 'no data' outcome, but for a NOT IN case it converts 'select everything, nothing excluded' into 'select nothing', which is the opposite of the business requirement and produces wrong results with no error raised at all going forward.

Add a code review checkpoint for any dynamically constructed WHERE clause: every fragment built from a range or select-option table must be preceded by an IS INITIAL check before being appended. Prefer the static Open SQL syntax with an inline table, such as WHERE field IN @itab, over string-concatenated dynamic WHERE tables wherever the condition does not genuinely need to be dynamic, since the static form lets the compiler optimize an empty table safely. Unit and regression tests for selection reports should always include a run with every optional select-option left blank.

ABAP development owns this dump; it is a logic defect in how a WHERE condition was assembled, not a basis or authorization issue. The handover note to development should include the ST22 call stack, the program and line of the failing SELECT, and the exact input (which selection field was left blank or which upstream table was empty) that reproduces it, so the fix can be tested against the same empty-table scenario before transport.

Sits alongside other SAPSQL_ family dumps raised by the dynamic Open SQL layer, notably SAPSQL_ARRAY_INSERT_DUPREC and SAPSQL_INVALID_FIELDNAME, all of which surface logic defects in dynamically constructed SQL rather than infrastructure problems. Frequently appears as an uncaught exception when the raising code has no local error handling, and the corrective pattern always involves either catching CX_SY_OPEN_SQL_DB deliberately with a validated fallback or, better, preventing the empty condition from reaching the statement at all.