RSDODSO table — RSDODSO Table Reference for BW DataStore Objects

Each row in RSDODSO represents one version of the definition of a single classic DataStore object (previously called an ODS object) in a BW system. This is metadata, not data: the row records that a DSO with a given technical name exists, in which version state it currently sits, and when it was last changed. Every classic DSO created in the Data Warehousing Workbench gets an active version row here once activated, plus in-flight modified or delivery version rows while a change is being worked on or transported. The table does not hold the DSO's actual records, its key fields, its data fields, or its size; those live in the DSO's own generated data tables and in the field-mapping metadata tables that hang off this header.

Only fields that are stable across BW releases and safe to rely on in an ad hoc read are listed here; internal type flags and activation settings sit in child tables, not in this header.

The joins that actually get written against RSDODSO are all keyed on ODSOBJECT, since that is the only stable identifier shared across the metadata and monitoring layers.

RSDODSO is small, typically a handful of rows per DataStore object, so it is never a lookup performance problem by itself. It is cross-client metadata, like most Data Warehousing Workbench objects, so there is no client field to restrict on; the definition is identical in every client of that BW system. Always filter on OBJVERS = 'A' when the question is what is actually active and running; ignoring the version field is the most common way to pull in a stale modified row left behind mid-change, or a delivery row that only exists because a transport was released but never activated in the target. Avoid wildcard searches on ODSOBJECT across a whole naming range unless the project's namespace convention is well understood, since prefixes get reused across unrelated data flows over the years.

Symptom: a DSO shows as inconsistent or will not activate in the modelling workbench, and someone insists no change was made. Selection: read RSDODSO where ODSOBJECT equals the DSO name, no version restriction, and look at the OBJVERS column across the returned rows. If both an A row and an M row exist for the same object, an un-activated change is sitting in the system, and that explains why downstream transformations further along the flow still see the old structure while the workbench shows a pending edit.

Classic DataStore objects and their RSDODSO header rows continue to exist in BW on HANA and in BW/4HANA for objects that have not been converted. BW/4HANA introduced the Advanced DataStore Object (ADSO) as the standard modelling object going forward, and ADSO metadata is stored separately, not in RSDODSO. Where a classic DSO has been migrated to ADSO, its RSDODSO entry effectively becomes historical; where it has not, RSDODSO remains the authoritative header for that object exactly as in classic BW.

Most of the wrong conclusions drawn from this table come from treating it as if it described data volume or runtime behaviour, when it only describes definition state.

Ownership of a question against RSDODSO sits with the BW data architect or modeller responsible for the layer the DSO belongs to, not with a functional module team. Basis is only interested in the size of the underlying data tables, not the header metadata. A version-state discrepancy is a modelling or transport question, and gets escalated to whoever owns the LSA or LSA++ layering for that data flow.

The DSO's own field-to-InfoObject mapping and activation queue live in separate child metadata tables that hang off RSDODSO by object name, and are maintained through the Data Warehousing Workbench rather than directly. Process chains reference the DSO in their load and activation steps, and their execution against a given DSO is logged in the process log table. Request-level load and activation status for the DSO is tracked separately, and monitoring of individual activation and SID-generation steps is recorded in the monitor detail table.