BALDAT table — Application Log Data Table

One row in BALDAT represents a chunk of serialized data belonging to a single application log entry created through the SBAL application log framework, the mechanism behind transactions SLG1 and SLG2. When a program calls the log-create and log-save function modules, a header row is written to BALHDR and the message texts, message parameters, and any attached context structures are packed into BALDAT under the same log number. The table is technically a pool or cluster table: its stored content is not organized as individual readable columns per message, it is a packed binary payload that the application log API unpacks on display. Consultants rarely query BALDAT for content directly; they query BALHDR to find the log they want, then let SLG1 or the log display function module render the actual text from BALDAT.

Only two fields can be relied on for direct selection; everything else in the row is packed data, not discrete columns.

The only join a consultant writes against BALDAT with confidence is back to the header table. Everything else about a log - who ran it, when, against which object and subobject, what severity - lives in BALHDR, not in BALDAT. Practical analysis therefore always starts in BALHDR and uses BALDAT only as the storage target that must exist for a log to display content.

Never select from BALDAT without restricting on MANDT and, ideally, a specific LOGNUMBER or a LOGNUMBER range already obtained from BALHDR. The table can carry an enormous number of rows in systems where logging is left at a verbose level and the log deletion job is not scheduled, so a plain full scan can time out or hammer the database. Do not attempt to read message content in SE16N or SE16 - the payload shown is a raw string with no readable structure. The correct path is: query BALHDR with business criteria (object, subobject, date, user) to get the log number, then open that log through SLG1 or feed the log number into the application log load/display function modules.

Symptom: a job or interface message says to check the application log, but SLG1 shows nothing for the expected time window. Select BALHDR by OBJECT, SUBOBJECT and the run's date/time to get the LOGNUMBER. If that LOGNUMBER exists in BALHDR but no rows exist in BALDAT for the same LOGNUMBER and MANDT, the log header was created but never saved through the save function module, so the message content was lost even though the header record survived.

BALDAT is unchanged moving from ECC to S/4HANA. The application log framework kept its original technical shape and was not exposed through a CDS compatibility view, because it is not designed to be queried by custom ABAP or reporting tools in the first place. The application log API and SLG1/SLG2 remain the supported access path in both releases; there is no alternate S/4-specific storage for the same data.

The recurring mistake is treating BALDAT as if it were a normal, human-readable table.

Basis normally owns the housekeeping side of this table: whether the log deletion/cleanup job is scheduled and whether BALDAT is bloating the database. The functional or development team that originally wrote the log entries owns the content question: why a given run produced a particular message. A report of missing or empty log content should go to the process owner first, not straight to a direct table lookup.

BALHDR is the header table and the mandatory starting point for any lookup, carrying object, subobject, date, time and user for each log. Background job tables TBTCO and TBTCP are relevant when the logs in question were raised by job steps reporting errors into the application log during a scheduled run, which is a common source of sudden BALDAT growth after a batch process starts failing repeatedly.