SAP Transport Tables: E070, E071 and What Each One Holds

Every SAP administrator eventually needs to answer a question the standard transactions do not answer well: which requests touched this table last quarter, who released them, which are still sitting unreleased in a departed developer's name, and what is actually inside them.

That means querying the transport tables directly. This is a reference for what each one holds and how they fit together.

One rule before anything else: read, never write. The Change and Transport System keeps these tables synchronised with the cofiles and data files in the transport directory. An update that makes sense in the database and not on the filesystem produces failures whose error messages point nowhere near the cause. Every query below is a SELECT.

The core four

E070 — request and task header

One row per transport request, and one row per task inside it. This is the table you start from.

STRKORR is the field that trips people up. Requests and tasks live in the same table; a task is distinguished by having its parent's number in STRKORR. If a count of "transport requests" comes out suspiciously high, this is usually why — filter on STRKORR = '' to get requests only.

E071 — the object list

One row per object in a request or task.

PGMID matters. R3TR means the complete object; LIMU means a part of one — an include, a single method, a table definition within a larger object. A search that only looks at R3TR will miss changes captured at the LIMU level.

OBJECT = 'TABU' means table contents rather than a table definition, which is how Customizing entries appear.

E071K — table key entries

For Customizing requests, E071 tells you *which table* was changed. E071K tells you *which rows*.

TABKEY is a concatenated key string, not separate fields, so parsing it requires knowing the table's key structure. This table gets large in landscapes with heavy Customizing, and it is the reason a Customizing request can be enormous while its E071 object list is short.

E07T — short texts

The request description. Separate table, keyed by TRKORR plus LANGU, because descriptions are language-dependent.

This is the single most common reason a hand-written transport report comes back with blank descriptions: the join to E07T was written without a language restriction, or with a language that has no entry. Restrict on LANGU explicitly.

Runtime and control tables

These are the ones people mistake for history.

`TRBAT` and `TRJOB` control background transport steps while an import is running. TRBAT holds the steps to be performed for the current import in the current system; TRJOB links them to the background jobs executing them. They are working tables — rows appear during an import and are cleared afterwards.

The practical use is diagnostic. If an import appears hung, TRBAT shows which step it is stuck on. If TRBAT has entries but no corresponding background job is running, the import has died and left state behind — a situation worth understanding before restarting anything.

`E070L` holds the number ranges used to generate request numbers. You will rarely touch it, but it explains the numbering: a request called DEVK900123 comes from the DEV system, and 900123 is the sequence.

`E070C` and `E070M` hold client and additional attributes for requests, including the source client for Customizing requests — useful when you need to establish which client a configuration change actually came from.

Queries worth having

Which request contains this object?

SELECT e070~trkorr, e070~as4user, e070~trstatus, e071~object, e071~obj_name
  FROM e071 INNER JOIN e070 ON e070~trkorr = e071~trkorr
 WHERE e071~obj_name = 'ZMY_PROGRAM'
   AND e071~pgmid    IN ('R3TR', 'LIMU')

Unreleased requests by owner — the housekeeping query, especially before a developer leaves or a system is refreshed:

SELECT e070~trkorr, e070~as4user, e070~as4date, e07t~as4text
  FROM e070 LEFT OUTER JOIN e07t
    ON e07t~trkorr = e070~trkorr AND e07t~langu = 'E'
 WHERE e070~trstatus IN ('D', 'L')
   AND e070~strkorr  = ''

Which requests touched a Customizing table:

SELECT DISTINCT trkorr FROM e071k WHERE objname = 'T001'

Adapt field lists to your release. The table and field names above are stable across ABAP releases; the status value sets are the part most worth verifying in your own system rather than trusting a blog.

When not to use these tables

For most day-to-day questions, the standard tooling is faster and safer:

• `SE03` → Search for Objects in Requests answers "which request contains this object" with a usable interface, and correctly handles the R3TR/LIMU distinction
• `SE01` shows a request's full contents, including key entries, without any SQL
• `STMS_IMPORT` shows the import queue and history for a system

Direct table access earns its place when you need something the transactions do not give you: a cross-landscape report, a scheduled audit extract, a bulk analysis before a migration, or a question about hundreds of requests at once.

Which is, in practice, exactly what comes up when planning an S/4HANA conversion — establishing how much custom code is genuinely in use, which requests are still open, and what will need remediation before the conversion. That analysis is a normal part of our S/4HANA migration work, and it starts here.

Related reading

• SAP Transport Management System (STMS): A Practical Guide — how the transport pipeline works
• SAP Transport Errors and Return Codes — diagnosing failed imports