BEx Query Shows No Data With Cube Populated
The cube has rows, but the query returns an empty grid or all-zero result. This is almost never a load failure. It is a filter, variable, authorization, navigational attribute, currency translation, or MultiProvider identification problem sitting between the InfoProvider and the query, silently excluding rows that are physically present.
Covers the case where LISTCUBE or a manual check confirms the InfoProvider holds the expected records but the BEx or Fiori query returns nothing. Walks through the ranked causes: restrictive variables, analysis authorizations, unactivated navigational attributes, currency translation failures, and MultiProvider identification gaps, with the check sequence and the branching resolution for each.
Published 16 Sept 2026· 1,068 words
The business symptom
Reported as: the report was fine yesterday and today it comes back blank, or the numbers are there in the source system but the dashboard shows zero. Sometimes it is partial: one plant or one cost center returns data and another does not, even though both were loaded in the same run. Business users typically escalate this as a data loss issue, assuming the extraction failed overnight, and ask for the load to be rerun. Occasionally the report shows a result but it is suspiciously low compared to a known total, which is a variant of the same underlying problem rather than a separate one. The complaint almost always references a specific combination of filters the user selected in the variable screen, which is usually where the real cause is sitting.
The configuration behind it
- Restrictive variable or filter value that does not match the granularity or exact value stored in the cube - a fiscal period variable defaulting to the wrong posting period, a text-entry variable with trailing spaces, or a customer exit variable returning a value nobody expects.
- Analysis authorization gap - the user's authorization object does not cover the characteristic values in the selected data (0BI_ALL is not assigned, or a new organizational value was never added to the authorization). The query returns empty with no error message, which is what makes this cause easy to miss.
- Navigational attribute used in the query filter or drilldown is not activated on the InfoProvider, or the attribute change run has not been executed since master data was updated, so the attribute value the user filters on does not exist for any transaction record from the query's point of view.
- Currency translation type attached to a key figure fails silently for records that have no valid exchange rate for the translation date, dropping those rows from the result set entirely rather than raising an error.
- MultiProvider or CompositeProvider identification issue - the underlying cube is correctly loaded but its characteristics or key figures are not properly identified against the MultiProvider the query is built on, so the query never sees that partition of data.
- Restricted or calculated key figure combined with constant selection interacting badly with the global filter, producing a structural null instead of a value.
- Hierarchy node filter referencing a hierarchy version that is inactive, or a node that no longer exists after a hierarchy attribute change, especially right after a hierarchy load.
What to check
- LISTCUBE or RSA1 data browser on the InfoProvider directly, using the exact same characteristic values the user selected, to confirm the rows genuinely exist at that granularity.
- RSRT - run the query in debug mode, check the generated SQL and the variable values actually passed at execution, not just the values shown on the selection screen.
- RSECADMIN - check the user's analysis authorization against the characteristic values in the failing selection; look specifically for missing 0TCAIPROV or missing values for the relevant navigational characteristic.
- RSD1 - check whether the navigational attribute used in the filter is marked as active for reporting on the InfoProvider, and whether the attribute change run has completed since the last master data delta.
- RSCUR - review the currency translation type on the key figure for missing or expired exchange rate entries for the relevant date.
- MultiProvider definition in RSD1 - verify the identification of characteristics and key figures between the query's MultiProvider and the specific InfoProvider that holds the rows.
- RSRV - run consistency checks on the InfoProvider and its master data if the above checks are inconclusive.
How to prove it in the data
Run LISTCUBE on the InfoProvider with the exact characteristic and period restriction the user applied in the query, and compare the row count and key figure sum against the query output for the same selection. If LISTCUBE shows rows and the query shows zero, the gap is proven to sit between the provider and the query - in the variable, the authorization, or the MultiProvider identification - not in the load.
Resolution path
If the cause is a variable default or filter value, the fix is a query design change in Query Designer, transported through the normal BEx transport route, not a data fix. If the cause is an authorization gap, the fix belongs to security or the BW authorization team, who adjust the analysis authorization object and reassign it, again a config change requiring transport, not a reload. If the cause is a navigational attribute not activated, activating it in RSD1 is config and needs transport, but running the attribute change run afterward is a data-side execution step that must be scheduled, ideally in the process chain, not run manually as a one-off. If the cause is currency translation, the fix is either loading the missing exchange rate as master data or correcting the translation type definition in RSCUR, which is config and needs transport. If the cause is MultiProvider identification, correcting the identification mapping in RSD1 is config and needs transport, followed by a metadata refresh, not a data reload.
The fix people try first (and why it fails)
The reflex is to delete and reload the InfoProvider, on the assumption that the data is somehow corrupted or missing. This wastes hours, disturbs any downstream aggregates or reporting on that provider, and changes nothing, because the data was already there and correctly loaded. It can also introduce a genuine problem where none existed, if the reload resets a delta queue or init flag on a source that was working fine, converting a query display issue into an extraction issue.
Whose problem this is
Ownership sits with the BW reporting or analytics team for query design and MultiProvider setup, and with the security or authorization team for analysis authorization content. The handover note should record the exact query technical name, the variable values used in the failing execution, the characteristic suspected of causing the filter mismatch, and the LISTCUBE comparison result confirming the data is present.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-functional-issues/query-returning-no-data-despite-records-in-the-cubeERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.