CODEWITHSUNDEEP
ssasforeign-key-relationshipdata-warehouseolap-cubedimensional-modeling
alejandro zuleta
alejandro zuleta

Reputation: 14108

Errors in the OLAP storage engine: The attribute key cannot be found when processing

I know this is mainly a design problem. I 've read that there is a workaround for this issue by customising errors at processing time but I am not glad to have to ignore errors, also the cube process is scheduled so ignore errors is not a choice at least a good one.

This is part of my cube where the error is thrown.

DimTime

FactBudget

The relation in DSV is set as follows.

DimTiempo = DimTime, FactPresupuesto=FactBudget, periodo = MyMonth, PeriodoPresupFK = Month Just translated for understanding.
enter image description here

The Relationship in cube is as follows: enter image description here

The cube was built without problem, when processing the errror: The attribute key cannot be found when processing was thrown.

It was thrown due to FactBudget has some Month values (201510, 201511, 201512 in example) which DimTime don't, so the integrity is broken.

As mentioned in the answer here this can be solved at ETL process. I think I can do nothing to get the relationship if one fact table has foreign keys that has not been inserted in dimensions.

Note MyMonth can be values 201501, 201502, 201503 etc. This is set for year and month concatenated, DimTime is incremental inserted and every day is calculated that column so in this moment DimTime don't have values for 201507 onwards.

Is there a workaround or pattern to handle this kind of relationships?

Thanks for considering my question.

Upvotes: 1

Views: 3898

Answers (3)

Carl
Carl

Reputation: 361

I ran into this issue while trying to process a cube in Halo BI. It seems that some "datetime" styles "are" supported by SQL Server but not Halo BI. This statement does not cause an error:

CAST(CONVERT(char(11),table.[col name],113) AS datetime) AS [col name]

however this does not process without an error:

CAST(CONVERT(char(16),table.[col name],120) AS datetime) AS [col name]

However both of these work in SQL Server Management Studio 2012.

Another cause of this error is due to the cube measures being improperly mapped to the fact table.

Upvotes: 0

LearnByReading
LearnByReading

Reputation: 1883

I believe that the process you are following is incorrect: you should setup any time related dimensions via a degenerate/fact dimension methodology. That is, the time dimension would not really be a true dimension - rather, it is populated through the fact table itself which would contain the time. If you look up degenerate dimensions you'll see what I mean.

Upvotes: 3

Jo Douglass
Jo Douglass

Reputation: 2085

Is there a reason why you're incrementally populating DimTime? It certainly isn't the standard way to do it. You need the values you're using in your fact to already exist in the dimensions. I would simply script up a full set of data for DimTime and stop the incremental updates of it.

Upvotes: 0

Related Questions