Skip to Content
0
Dec 11, 2013 at 09:44 PM

Invalid key figure error after reactivating analytic view

253 Views

Hi folks,

I have an analytic view that has been working fine with no problems for months. Recently I added a non numeric field to it and moved into production via IMPORT of delivery unit and began getting error below. So I reverted back to original by importing the previous TGZ file before this change however I get the same error using original view. My suspicion is that it is not working due to 68 upgrade yet this is the first time we have reactivated the view since upgrade and perhaps only reason it has worked post-upgrade is because we have never re-activated the view.

To elaborate more on the exact error; we have a microstrategy report against the analytic view that is performing a SUM on a key figure that is NOT derived from the primary fact table of the analytic view. In fact it's defined as an ATTRIBUTE (decimal data type) however the microstrategy developer was doing a SUM and converting it to a measure inside microstrategy. This was working fine all along until I tried to change the view and/or activate the original.

I was wondering if somehow it was related to new setting in 68 for analytic view 'Multidimensional reporting' option. This seems to be checked by default which I was thinking it would mean we can not aggregate other metrics from non primary fact table. But when I toggle this off and try I get the same error;

AP DBTech JDBC: [2048]: column store error: search table error: [6900] Error executing physical plan: exception 6900:

AttributeEngine/Parallel/Aggregation.cpp:4502

Attribute engine failed; $function$=createAggregators; $message$=invalid keyfigure PRD:_SYS_SPLIT_MSEG~13en 0x00007f7680964be0

,in executor::Executor in cube: _SYS_BIC:production.

Now I can tell by the error it's searching for my metric inside a partition inside MSEG however this particular metric being summed truly does not exist in MSEG and is actually in EKPO table being joined inside the analytic view. So how come HANA could resolve and find this field before however now after 68 it seems it can not?

Any ideas?

Thanks,

-Patrick