RSDIOBJ table — RSDIOBJ - InfoObject Metadata Repository Table

One row in RSDIOBJ represents a single InfoObject at a single object version - one characteristic, key figure, time characteristic, or unit, as it exists in one state of the BW metadata repository (active, modified, or delivered). The row carries the object's technical shell: its data type, internal length, output length, object category, and flags indicating whether that object has its own generated text table, attribute table, or hierarchy table. It does not carry master data values, and it does not carry the full characteristic-specific or key-figure-specific configuration such as the navigation attribute list, aggregation behaviour, or compounding chain - those sit in companion tables keyed the same way. Every place in BW that resolves an InfoObject name to a concrete technical field - query definition, InfoProvider generation, DataSource-to-InfoObject mapping in a transformation - ultimately traces back to a row here.

The table is keyed on INFOOBJECT and OBJVERS, and almost every join back to it uses both fields together, because an object can exist simultaneously as active, modified, and delivered, and reading the wrong version returns stale or half-transported settings. Characteristic-only and key-figure-only properties sit in separate tables joined the same way. Consumption by an InfoCube or a DSO is not a direct foreign-key join against RSDIOBJ - the InfoProvider's own metadata stores the InfoObject name as a value, and the InfoObject's dedicated master data, SID, text and hierarchy tables are generated dynamically using that name as part of their own table name, not through a link stored in RSDIOBJ itself.

RSDIOBJ is a client-independent repository table, there is no MANDT field to restrict on, and a change to an InfoObject's definition is visible across every client on that system as soon as it is activated, with no client-copy step involved. The table has one row per InfoObject per version, so its size is modest compared with transaction or master data tables, but selectivity still matters when scanning it broadly: restrict on OBJVERS first, almost always to the active version A, before looking at anything else, because the same InfoObject name will also show up with M and D rows that reflect a saved-but-not-activated change or the originally delivered content version. Restrict further by namespace prefix (0 for SAP-delivered content, a custom prefix for local objects) when doing a wide search rather than looking up one known name.

Symptom: a query shows a truncated or unexpectedly formatted value for a characteristic, and someone suspects the InfoObject's definition was changed but not deployed. Select RSDIOBJ where INFOOBJECT equals the object name and OBJVERS equals A to see the length, output length and data type that are actually live. Run the same selection with OBJVERS equal to M for the same object name; if that row exists and differs from the A row, a change has been saved in the modelling transaction but never activated, which explains why the live behaviour has not changed.

On S/4HANA systems that run embedded BW or that connect to a standalone BW/4HANA system, RSDIOBJ remains the native repository table for InfoObject metadata; it has not been replaced by a CDS compatibility view because InfoObjects are a BW modelling construct, not part of the ABAP CDS-based virtual data model that S/4HANA analytics also offers as a separate stack. The two worlds coexist rather than one replacing the other, and a characteristic defined as an InfoObject will always trace back to a row in this table regardless of which S/4HANA deployment option is in use.

The BW modelling team or BI competence centre owns any change to what this table holds, and changes are made exclusively through the InfoObject maintenance transaction, never through direct table edits. Basis gets involved only if the underlying database object itself is corrupted or oversized. Functional consultants care about this table only as far as a characteristic's technical type or length is producing a visible reporting defect.

RSDCUBE and the DSO metadata equivalent record which InfoObjects an InfoProvider carries as dimensions or key figures, consuming InfoObject names defined here. DataSource field metadata can reference an InfoObject as a template to inherit its data type and conversion behaviour when the field is created. The InfoObject maintenance transaction is the only supported entry point for writing to RSDIOBJ; the transport system, not direct table edits, is what moves changes between systems.