We use the same test cube as in Example III, but check an affected query instead of analyzing an issue in LISTCUBE. The sample query is very simple, it only has the characteristic GLCOUNTRY7 and two basic key figures in the drilldown. In addition there is the interval filter GLCOUNTRY7 = AT - DE.
We run the query in RSRT and have the SQL/Hana Query displayed:
The Hana column view is accessed. The query result is as follows:
Now we run it again but switch off the usage of the Hana index (not for all providers possible, e.g. queries based on a HCPR cannot use SQL)
The query uses now SQL to retrieve the data from the InfoCube.
You can see that there is one more row displayed! There is obviously somthing wrong here, but what exactly? Why is there a difference between SQL and Trex API?
Since such an issue can be caused by inconsistencies in transaction or master data tables we take a closer look at the statements. In the SQL statement we can see that basically three tables are invloved, the fact table, dimension table (package dim) and the SID table of GLCOUNTRY7. Unfortunately, when checking the trex statement no information can be found regarding the tables. Only the column view is mentioned. Hence we need to take a closer look at the definition of the column view. This e.g. can be done in the Hana Studio:
Since the cube GLCUBE7 has an active navigation attribute of the charcteristic GLCOUNTRY7,
the definition of the column view contains the X-table instead of the SID table. This is the decisive difference in comparison to the usage of SQL. The transaction RSRV offers the possibilty to check the master data. We use the check 'Compare sizes of P or Q and X or Y tables'(see RSRV). In general it makes sense to check all characteristics fo the affected Infoprovider:
It is not surprising that an inconsistency was found for the characteristc GLCOUNTY7. RSRV offers in such a case the possibilty to repair the error: