TADIR table — TADIR Repository Object Directory Table
TADIR is the SAP repository object directory. One row represents one repository object known to the system, identified by object type and name, together with the development package it belongs to, its original language, the person who created it, and the transport request that last changed it. It is the master list the Workbench and transport tools consult to know an object exists.
This page covers TADIR, the table that lists every repository object in the system along with its package, author, and last transport request. It focuses on how consultants actually use TADIR to trace ownership, package assignment and transport history, and on the false conclusions people draw from it when the directory and the underlying object have drifted apart.
Published 15 Sept 2026· 1,165 words
What it stores
Each row in TADIR represents one repository object registered in the system: a program, a table, a class, a function group, a transaction code, a message class, and so on. The row does not hold the object's content or logic, only its identity and administrative metadata: which development package it lives in, what its original source language was, who created it, when it was last changed, and which transport request last carried a change to it. TADIR is populated automatically whenever an object is created through the ABAP Workbench, and it is the table the transport organizer and the object navigator consult to answer the basic question 'does this object exist, and where does it belong'. It is not a runtime table and holds no business data.
Key fields
- MANDT - client, though most repository objects are cross-client and this field is often blank or 000
- PGMID - object category, typically R3TR for a whole object or LIMU for a sub-object entry
- OBJECT - object type code, for example PROG for a program, TABL for a table, CLAS for a class, TRAN for a transaction
- OBJ_NAME - the object's technical name within that type, for example the program name or table name
- DEVCLASS - the development package the object is assigned to
- AUTHOR - the user ID recorded as the creator of the object in this system
- MASTERLANG - the original logon language the object was created in
- KORRNUM - the last transport request that carried a change to this object
- GENFLAG - flag indicating the object was generated automatically rather than created directly by a developer
- DELFLAG - flag indicating the object has been marked for or is in the process of deletion
How it joins the data model
- TADIR-OBJ_NAME = TRDIR-NAME, restricted to OBJECT = 'PROG', to get a program's runtime attributes
- TADIR-OBJ_NAME = DD02L-TABNAME, restricted to OBJECT = 'TABL', to get a table's delivery class and DDIC status
- TADIR-OBJ_NAME = SEOCLASS-CLSNAME, restricted to OBJECT = 'CLAS', to get a class's category and instantiation type
- TADIR-OBJ_NAME = TSTC-TCODE, restricted to OBJECT = 'TRAN', to link a transaction code to its package and author
- TADIR-PGMID/OBJECT/OBJ_NAME = E071-PGMID/OBJECT/OBJ_NAME to see which transport request an object's directory entry belongs to
How to read it safely
TADIR is large but each query should be narrow: always restrict on OBJECT before OBJ_NAME, since the same name can exist under different object types and a scan without the type filter returns misleading rows. The client field is mostly irrelevant since repository objects are cross-client, so do not waste selectivity there. DEVCLASS is a good filter when investigating everything in a package, but package names starting with dollar sign, particularly $TMP, mean the object is local and was never assigned a real package or transport, which explains why it will not show up in E071. Avoid full scans by OBJ_NAME alone across the whole table; always pair it with OBJECT.
How to prove it in the data
Symptom: a developer says a custom program cannot be found or transported. Select TADIR where OBJECT = 'PROG' and OBJ_NAME equals the program name. If no row returns, the program was never registered, most likely created outside the Workbench or already deleted. If a row returns with DEVCLASS = '$TMP', the program is a local object and was never assigned to a transportable package, which explains why no transport request picked it up.
ECC vs S/4HANA
TADIR is Basis infrastructure, not application data, and it is unchanged in shape and purpose on S/4HANA. It continues to be the object directory consulted by the classic Workbench transactions and by ABAP Development Tools in Eclipse alike. No compatibility view was introduced for it because it sits below the business data layer that CDS view replacement addresses; the transport and repository infrastructure it belongs to works the same way regardless of the underlying application stack.
Common pitfalls
- A TADIR row existing is not proof the object is still functionally intact. Directory and object can drift apart if the object was removed by unconventional means, for example direct database manipulation or an interrupted deletion, leaving an orphan entry with DELFLAG set or a phantom entry with none set.
- DEVCLASS shown here is the current package assignment, not the transport layer the object was originally released through or the system it currently resides in. Do not infer landscape routing from DEVCLASS alone; check the package's transport layer separately.
- A missing TADIR entry does not always mean the object never existed. Objects in a local package ($TMP) or generated objects with GENFLAG set may be excluded from the searches a consultant expects, particularly when searching E071 for a transport that should have carried the object.
- AUTHOR reflects who technically created the object in that particular system, which after a transport into a downstream system is often the background transport user, not the original developer. Do not use AUTHOR as a business ownership record.
- PGMID = LIMU rows represent sub-object entries tied to a parent R3TR object, for example a single table field change bundled inside a larger structure change. Treating LIMU rows as standalone objects when reconciling a transport request produces confusing duplicate-looking entries.
- KORRNUM only records the last request that touched the object, not the full change history. Reconstructing an object's full transport lineage requires E071 and E070 for that object, not TADIR alone.
- Recreating an object after a failed or partial deletion can fail with an 'already exists' error even though the object appears gone functionally, because the TADIR entry was never cleaned up. This needs a directory-level fix, not a repeat of the create action.
Whose problem this is
Questions about TADIR content belong to the Basis or ABAP development team, specifically whoever administers the transport landscape and the development packages. A functional consultant who finds an inconsistency here should raise it with development, not attempt a direct table fix, since TADIR entries are meant to be maintained exclusively through the Workbench and transport tools.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/tadirERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.