REPOSRC table — Program Source Administration Table

One row in REPOSRC represents the administrative entry for a given ABAP program name in a given version state, active or inactive. When a developer changes a program and does not activate it, two entries can exist side by side, one marked active and one marked inactive, until activation reconciles them. The table is part of the source management layer introduced to separate program administration from the raw source text, which is stored elsewhere and accessed through the editor and generation tooling rather than direct table read. REPOSRC therefore answers questions like whether a program has an unreleased inactive version pending, not what the program's logic actually says. It covers reports, includes, function group includes, module pools, and the generated include programs behind classes and function modules, since all of these are technically ABAP programs.

Always restrict by PROGNAME first; this table has one row per program per version state across the entire system, so an unrestricted select is effectively a full repository scan and will be slow or blocked in a shared system. Restrict R3STATE to the active version unless the question is specifically about pending inactive changes. The client field is not a meaningful selectivity lever here because repository objects are cross-client in behavior even though the table carries a client column; do not expect different content per client on the same system.

Symptom: a program's runtime behavior does not match what appears in the editor, or a transport seems to have picked up an unreleased change. Select REPOSRC where PROGNAME equals the program name, with no restriction on R3STATE, and look at how many rows come back. Two rows, one active and one inactive, confirms there is an unreleased version sitting alongside the active one, which explains the mismatch until someone activates or resets it.

REPOSRC continues to exist on S/4HANA with the same purpose, since it belongs to the ABAP kernel's source management layer rather than to any business data model that S/4HANA restructured. There is no business-layer CDS compatibility view over it because it is not a business table; it is consulted by development tooling such as the ABAP editor, transport handling, and program activation, and that mechanism did not change with the S/4HANA conversion.

A data question on REPOSRC belongs to the ABAP development or Basis team, not to a functional module owner. Functional consultants rarely have a reason to query this table directly; when a program's state looks wrong, the correct escalation path is the developer who owns the object, using the editor and transport tools rather than direct table maintenance.

TRDIR carries the parallel program attributes record for the same PROGNAME. TADIR provides the repository object directory entry, package, and transport layer for report-type objects. E070 and E071 record the transport request and its object list when a program's source changes get released and moved between systems. SEOCLASS and SEOCOMPO sit behind class pool programs whose generated include names show up as PROGNAME entries in this table. Transactions SE38, SE80, and SE03 are the normal tools that read and write this administrative state; none of them should be bypassed with direct table edits.