The dimensions in the cube are giving us duplicates, there is no error while processing the cube, but when the cube is browsed we could see duplicates.

There is a hierarchy in our dimension, the hierarchy is built like Country -- State -- Area.

In the DB, the dimension data looks something like below.

| Country |   State    |  Subarea  |
| India   | Karnataka  | Bangalore |
| India   | Telangana  | Hyderabad |

Now, when the cube is browsed with the attribute Country, we see 2 members under country as "India", when measure is selected against the attribute, the sales are shattered between these 2 values.

Can we do any work around to avoid this problem?

1 Answer 1


That behaviour is dependent on your KeyColumns setting.

Given a cube with these 2 named queries in the datasource view


SELECT        1 AS id, 'India' AS country, 'Calcutta' AS city
SELECT        2 AS id, 'India' AS country, 'Bangalore' AS city


SELECT        1 AS city, 5 AS salesamount
SELECT        2 AS city, 5 AS salesamount

A dimension based on cities, linked to the Sales table on the sales.city->cities.id relation that looks like this, using the id column as KeyColumns:

enter image description here

The result is this:

enter image description here

However, if I change the KeyColumn property to country for that attribute like this:

enter image description here

The result is all sales are reported under one single country:

enter image description here

I agree the documentation is a bit terse:

Contains the column or columns that represent the key for the attribute, which is the column in the underlying relational table in the data source view to which the attribute is bound. The value of this column for each member is displayed to users unless a value is specified for the NameColumn property.

Where you should interpret it as "there is one separate attribute member for each distinct value in the key column, even if the displayed value is the same"

Do note however that changing the key column might require you to change the NameColumn and the OrderBy properties.

Also, KeyColumns can be comprised of multiple columns acting as a unique key instead of a single key like in my example.

Sometimes when it's too risky for existing reports to change the structure already in place it might be a good option to add an extra attribute.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.