POSTING_ILLEGAL_STATEMENT — POSTING_ILLEGAL_STATEMENT Runtime Error

This is not an ABAP syntax error and the program is syntactically correct. The database interface layer inside the kernel maintains state about what is currently open on the database connection for the running LUW: open cursors, pending commit or rollback processing, and the call context of function modules. When ABAP code issues a database-changing statement while that state says posting is not currently permitted, the kernel aborts the statement and raises this dump instead of letting an inconsistent write reach the database. Because the trigger depends on runtime state rather than syntax, the same line of code can run cleanly for months and then dump the first time a particular data path opens a cursor and modifies the same table before closing it, or the first time a called function module tries to commit inside a context that already owns the LUW.

If the cause is an open cursor conflict, restructure the code so the SELECT loop only reads data; collect the keys or full rows into an internal table, close the loop, and perform the INSERT/UPDATE/DELETE afterward against the internal table, ideally as a single bulk statement. This is a code change and needs a transport through the normal change request process. If the cause is a nested COMMIT WORK, remove the explicit commit from the called function module and let the calling program or the update task own the LUW boundary; this also requires a code change and, if the function module is standard, a custom wrapper rather than a direct modification. If the cause is a disallowed event or exit, move the posting logic out of that event into a point in the processing flow where posting is permitted, such as after PAI processing completes rather than inside PBO. If the cause is recursive CALL TRANSACTION, restructure so the second posting is queued (batch input session or background job) rather than called synchronously from inside the first posting's commit phase. None of these are configuration fixes; all involve code review and a transport.

The reflex is to wrap the failing statement in a TRY/CATCH block, catch the resulting exception, and let the program continue, or to add a COMMIT WORK AND WAIT before the failing statement hoping it clears the blocked state. Both hide the dump without fixing anything: the write that failed still does not happen, so the record is silently left unposted or half-updated, and the same defect resurfaces the next time the same data path runs, usually discovered later as a missing document or an inconsistent table rather than a dump.

Treat SELECT...ENDSELECT combined with a database write against the same table inside the loop as a code review rejection; the standard should require SELECT INTO an internal table followed by a separate update step. Function modules that might run under an existing LUW should never issue their own COMMIT WORK; that decision belongs to the caller. Code inspector or ATC checks can be configured to flag COMMIT WORK inside function modules and SELECT loops with nested Open SQL writes on the same table, catching the pattern before it reaches production.

This is an ABAP development problem, not Basis. Basis may be the first to see it in a background job log and should pass it straight to the development team owning the failing program or function module rather than restarting the job repeatedly. The handover note should include the ST22 dump ID, the exact source line, the call stack, and whether the failure is reproducible with the same data set.

Commonly appears alongside cursor-handling problems such as DBIF_RSQL_INVALID_CURSOR when the same open-cursor pattern is mishandled differently, and near SAPSQL_ARRAY_INSERT_DUPREC when the deferred bulk write chosen as a fix hits a key collision instead. Nested update-task conflicts sometimes surface as CALL_FUNCTION_CONFLICT_TYPE if the wrong calling mode is used instead. If the surrounding code catches and rethrows the failure poorly, it can present downstream as an UNCAUGHT_EXCEPTION rather than the original dump.