RSDCUBE table — InfoCube Definition Header Table

One row in RSDCUBE represents a single object version of a single InfoCube's core definition: its technical name, its version status, and the type of provider it is. The table is the metadata anchor for the InfoCube - it does not contain the transaction data (that lives in the generated fact and dimension tables), and it does not list which characteristics or key figures the cube uses (that is held in a separate cube-to-InfoObject assignment table). Because BW versions metadata objects the same way across the board, a single InfoCube typically has more than one row here: an active version, a modified version pending activation, and sometimes a delivered content version. Consultants query RSDCUBE to confirm an InfoCube exists, to check its current activation state, or to distinguish between what is live in production and what a developer has changed but not yet activated.

RSDCUBE is BW metadata, not transaction data, and in most systems it is client-independent, so there is no client field to restrict on. Row counts are naturally small - one row per InfoCube per version state - so selectivity is high the moment the technical name is known; the expensive mistake is scanning the table without an INFOCUBE filter across a system with hundreds of cubes and multiple version rows each. Always add OBJVERS = 'A' unless the question is specifically about what is pending activation, otherwise duplicate-looking rows for the same cube name create false alarms.

Symptom: activation of an InfoCube fails or a developer reports a cube that behaves inconsistently after a transport. Select RSDCUBE where INFOCUBE equals the cube name with no OBJVERS restriction. Two or more rows with different OBJVERS values and mismatched CUBETYPE or other attributes confirm an inconsistent state between the active version and a modified or delivered version that never got activated, which explains activation errors or attribute mismatches downstream.

RSDCUBE continues to exist and function for classic InfoCubes running on BW-on-HANA and in embedded BW inside S/4HANA, since the underlying InfoCube object type has not been removed from those stacks. Newer BW modeling, particularly in BW/4HANA-oriented projects, favors advanced DataStore Objects and CompositeProviders over classic InfoCubes, so new development increasingly bypasses RSDCUBE in favor of the catalog tables behind those object types, but existing InfoCubes and their RSDCUBE entries are not automatically converted or removed.

This is a BW/BI modeling and administration question, not a functional module question. When an InfoCube looks wrong at this level - stuck in modified state, inconsistent version, unexpected type - the first call is the BW developer or BW administrator responsible for that data flow, not the source-system functional consultant, since the fix happens inside the Data Warehousing Workbench, not in the source application.

RSDODSO is the equivalent catalog table for DataStore Objects and gets checked the same way when a data flow spans both object types. RSDIOBJ holds the InfoObjects that a cube's dimension and characteristic assignment table refers back to. ROOSOURCE, ROOSFIELD and ROOSGEN describe the extraction side upstream of the cube. RSMONICDP, RSREQDONE, RSPCCHAIN and RSPCPROCESSLOG all reference the InfoCube as a load target or process chain step and are the tables to check for load history and scheduling once RSDCUBE confirms the cube's own version state. The Data Warehousing Workbench transaction is where InfoCube creation, editing and activation write to this table.