E070C table — Change Request Client Attributes Table

Each row in E070C ties a transport request or task number to a client in which that request captured client-specific changes. A workbench request that only touches cross-client objects may have no meaningful entry here beyond the recording client; a customizing request that was worked on across several clients in a landscape can produce multiple rows, one per client, because customizing entries are inherently client-dependent even though the request header itself lives at the client-independent level. The table exists so the transport control programs know, at import time, which client-specific data belongs to which client rather than assuming everything transports into the single logical target client. Functional consultants rarely query this table directly; it surfaces when transport behaviour needs to be explained rather than when data needs to be reported.

E070C is a client-independent table, so a selection without any WHERE clause returns rows for every client that ever recorded entries against a request, across the whole transport history of the system. Always restrict by TRKORR first when investigating a specific request; the table is small enough that a full scan is cheap on most systems, but building the habit of restricting by TRKORR avoids confusion when several thousand old requests are present. There is no meaningful selectivity gain from restricting on CLIENT alone since the table is tiny compared to genuine transaction data tables.

A customizing change appears in the target system but functional testing in a second client shows the old value. Select E070C where TRKORR equals the request number and inspect which clients appear. If the testing client is missing from the result, the customizing entry for that request was never recorded in that client, which explains why the change is invisible there regardless of import status.

E070C is a core Basis table underpinning the Change and Transport System and has not been replaced or restructured for S/4HANA. Its structure and usage are unchanged because the transport mechanism itself is unchanged; S/4HANA-specific transport tooling around it, such as tooling for cloud-based systems, sits alongside it rather than replacing it.

This is Basis territory. A functional or ABAP consultant investigating why a customizing change did not surface in a particular client should raise it with the transport administrator, who can read E070C alongside the transport logs and import history rather than guessing from the functional side.

E070 holds the request header that E070C attaches to. E071 lists the individual objects inside the request and is the natural next join once the client context is understood. E071K carries key-level entries for customizing objects with sub-keys, useful when a customizing table has more than one client-dependent entry per request. The Transport Organizer transaction is where all of this is normally viewed together rather than queried table by table.