TRDIR table — TRDIR ABAP Program Directory Table
TRDIR stores one row per ABAP program (report, module pool, include, function group, class pool, interface pool) holding its type, status, unicode flag, logical database, and the creator and change stamps. It is the runtime directory the ABAP loader and dictionary consult before compiling or executing a program, distinct from TADIR which tracks the program as a transportable repository object.
This page covers what TRDIR actually stores versus what people assume it stores, the fields worth querying, and the joins to TADIR, REPOSRC, TSTC and TFDIR that a consultant needs when tracing a dump, a missing transaction, or a unicode activation problem. It also flags the classic mistake of treating TRDIR as a source of business or authorization data.
Published 15 Sept 2026· 1,073 words
What it stores
One row in TRDIR represents a single ABAP program known to the system kernel, identified by its program name. This covers executable reports, module pools, includes, function groups (as generated programs), class pools and interface pools, subroutine pools generated for BDC or dynamic ABAP, and generated programs behind things like Smart Forms or screen painter output. The row carries the program's type and subtype, its unicode-compatibility flag, whether it is flagged as fixed point arithmetic, its logical database assignment if any, and administrative stamps for who created or last changed it and when. TRDIR is populated and maintained by the ABAP runtime and the Repository Information System whenever a program is generated, activated, or its attributes are changed in the ABAP Editor, not by application transactions.
Key fields
- NAME - the ABAP program name, primary key, matches SY-REPID at runtime
- STATE - status of the program, P for active/productive, N for new/not generated
- SUBC - program subtype, 1 executable, M module pool, F function group, S subroutine pool, I include, K class pool, J interface pool
- CNAM - user name of the program's creator
- CDAT - creation date
- UNAM - user name of last change
- UDAT - date of last change
- UCCHECK - unicode syntax check flag, X if the program is unicode enabled
- LDBNAME - logical database assigned to the program, blank if none
- RSTAT - program status indicator used by the repository (system, customer, test, etc.)
How it joins the data model
- TRDIR-NAME = TADIR-OBJ_NAME where TADIR-OBJECT = 'PROG', links the runtime program to its transport package and original system
- TRDIR-NAME = REPOSRC-PROGNAME, joins to the actual source code lines and the source's own metadata
- TSTC-PGMNA = TRDIR-NAME, links a transaction code to the program it starts
- TFDIR-PNAME = TRDIR-NAME, links a function module to the generated group include program that implements it
How to read it safely
TRDIR is client-independent; there is no MANDT field, so a lookup returns the same row regardless of logon client. It is small relative to most application tables but still spans every program in the system including SAP standard code, so always restrict on NAME with a pattern (LIKE 'Z%' or 'Y%' for custom code, or an exact name when chasing a specific dump) rather than pulling the whole table. Selecting on SUBC alone to find 'all function groups' or 'all classes' is technically possible but slow and rarely the right question - go through TADIR or the class/function directories instead and use TRDIR only to check the generated program's own attributes.
How to prove it in the data
Symptom: a program compiles or activates cleanly in one system but throws a unicode syntax error in another. Select TRDIR where NAME equals the program name and check UCCHECK. If it is blank or space in the failing system and X in the working one, the program was never regenerated with unicode checks active there, which is a generation/activation gap, not a code defect. Compare against REPOSRC for the same program to confirm the source itself is identical across systems before concluding it is a TRDIR flag issue.
ECC vs S/4HANA
TRDIR continues to exist in S/4HANA as part of the classic ABAP runtime and dictionary layer; it has not been replaced by a CDS compatibility view in the way many application master data tables have. Its role is unchanged - the kernel still consults it whenever a program is loaded or generated. What has changed on S/4HANA projects is that a much larger share of relevant logic sits in classes and CDS views rather than classic reports, so TRDIR investigations are proportionally rarer than in an ECC-era custom code base.
Common pitfalls
- Treating TRDIR as the source of truth for authorization or transport ownership - that is TADIR and the transport tables (E070, E071), not TRDIR. TRDIR only knows the program exists and its technical attributes.
- Assuming a program missing from TRDIR means it was deleted from the system - it may simply never have been generated (state N), for example a function module whose group include has not been triggered since the last code change.
- Reading CNAM/UNAM as reliable audit trail for who wrote the business logic - these fields reflect the last generation or attribute change, which can be a system user or a mass regeneration job, not the actual developer.
- Assuming SUBC alone tells the full story for class pools - class pool programs appear here as generated wrapper programs named after the class, and the meaningful class metadata (visibility, superclass, interfaces) lives in the class dictionary tables, not in TRDIR.
- Joining TRDIR to TSTC and expecting every transaction to resolve to a program - some transactions start via a start object or a Fiori mapping and never populate a direct PGMNA reference the way an old dialog transaction does.
- Using UCCHECK as proof a program actually runs correctly in unicode - it only reflects that the syntax check passed at generation time, not that runtime behavior with unicode data is correct.
Whose problem this is
This is technical basis/ABAP territory, not a functional master data question. A basis or development-support consultant checks TRDIR when chasing a dump, a generation error, or a unicode activation gap. Functional consultants should escalate to development rather than trying to interpret STATE or SUBC values themselves, since a wrong read here is often mistaken for a missing authorization or transport issue.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/trdirERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.