DBIF_RSQL_TABLE_UNKNOWN — Database Table Unknown Runtime Error

This dump comes from the database interface layer, not from the ABAP Dictionary check that normally happens at syntax-check or generation time. It means the kernel sent a SQL statement to the database naming a table that the database catalog does not recognize, or that the interface's internal buffer has no valid mapping for. The exception class is DBIF_RSQL_TABLE_UNKNOWN, and it terminates the work process immediately because Open SQL has no way to recover from a table that literally is not there from the database's point of view. It is distinct from a straightforward SE11 activation error: the program compiled and started running, so at some point the interface believed the table existed, and only failed when the actual data access was attempted. That timing gap is the first clue to where the real fault lies.

If SE14 shows the DDIC object active but the database object missing or inconsistent, run the database utility's adjustment/activation for that table to create the physical object; this is a Basis-executed fix and generally does not need a change request if done directly in a maintenance window, though it should still be logged. If the cause is a transport that omitted the table, re-transport the full DDIC object (not just the program) and re-run the adjustment in the target system; this does need a transport request. If the cause is a dynamically built table name resolving to a wrong or nonexistent value, the fix is in ABAP: validate the table name against DD02L or a whitelist before issuing the dynamic SELECT, and correct the logic that derives the name; this always needs a development change and transport. If the table was dropped directly on the database, restore it from a DDIC-driven creation (SE14) rather than a database backup restore, unless data recovery is also required, in which case Basis and the DBA team coordinate a table-level restore.

The reflex is to re-activate the DDIC object in SE11 and assume that alone fixes it, without ever opening SE14 to check whether the database side was actually adjusted. Activation only updates the dictionary's active version; it does not guarantee the physical table gets created or altered on the database unless the adjustment step is triggered and completes without errors. Another common reflex is to wrap the SELECT in a TRY/CATCH for CX_SY_OPEN_SQL_DB and swallow the exception, which stops the dump but leaves the program silently skipping data it needs, turning a visible failure into a quiet data gap.

Make table adjustment a mandatory, checked step in every transport and system copy procedure, not an optional cleanup task run only when something breaks. For any code that builds table names dynamically, add an explicit existence check against DD02L or use RTTI to confirm the resolved name before issuing Open SQL, and log the resolved name for troubleshooting. Restrict direct database access outside of SAP tooling to break-fix situations with Basis sign-off, since undocumented drops are hard to trace after the fact.

Basis owns DDIC-to-database inconsistencies, adjustment runs, and system-copy follow-up. ABAP development owns dynamic SQL logic and any table-name resolution bugs. The handover note should state the exact table name from the dump, whether the SELECT was static or dynamic, the SE14 comparison result, and the system/client where it occurred.

Closely related dumps from the same database interface family are DBIF_RSQL_SQL_ERROR, DBIF_RSQL_INVALID_CURSOR, and DBIF_RSQL_INVALID_REQUEST, which cover other database interface failures rather than a missing table specifically. The transactions most involved in diagnosis and fix are SE11, SE14, and ST22 itself; the DDIC tables DD02L and DD03L are the reference point for confirming whether a table is genuinely active.