Skip Consolidate or Blank value in String Cube

[hyunjia]

Hi

In one of my projects , I need to generate all string value from a mapping cube ( String cube , all string value are stored against N element ) .

I include all elements in a subset for each dimension , and set the view property by ViewExtractSkipCalcsSet and ViewExtractSkipZeroesSet both = 1 . In doing so , I expect the view could display all string value in N element , thus without contruct those subsets one by one . However , it seems these 2 functions don't work as they do for numeric cells ?

Has anyone encountered such scenario before ? or just I didn't use them properly. Please help !!

[rozef]

all string value in N element

I assume you mean that string value are stored at leaf level? Because N type is for numeric value.
The only reason I can see is that your string values are calculated, in which case you will have to set ViewExtractSkipRuleValuesSet at 0.

A good way to debug your process would be to build manually your view.
Or even better, dont destruct it in your process, then you can open it and see what's going on.

[hyunjia]

all string value in N element

I assume you mean that string value are stored at leaf level? Because N type is for numeric value.
The only reason I can see is that your string values are calculated, in which case you will have to set ViewExtractSkipRuleValuesSet at 0.

A good way to debug your process would be to build manually your view.
Or even better, dont destruct it in your process, then you can open it and see what's going on.

Hi , thanks for the advise . Yes , string value is inputted in leaf level and no rule-driven value as well . Actually , I have done a test : right click on the cube and select export data , select skip rule and skip consolidated element options . it appears that no value will be exported even with this manual way .

This is pretty annoying as sometimes user might inputted string value in consolidate element .

[Duncan P]

There was a bug in this area in either 9.5 or 9.4, specifically to do with exporting string values with one of the options. I can't remember the details but I would recommend that you do some tests.

Create a small test cube with one simple hierarchy and a measure dimension with two string measures. In the rule file leave one of the string measures and calculate the other from the first by appending something. Then enter data for the first measure at all levels of the hierarchy and try out all combinations of settings in the export dialog making sure that what gets exported matches what you expect.

It also helps if, when you are reporting unusual behaviour, you mention the exact version you are seeing it in.

I look forward to hearing your results.

[tomok]

Yes , string value is inputted in leaf level

This is pretty annoying as sometimes user might inputted string value in consolidate element .

Your facts are in direct contradiction. First you say strings are entered at the leaf level and then you say that the supposed "bug" is annoying because users may input at the consolidated level. Which one is it? If you are setting ViewExtractSkipCalcsSet to TRUE then it is going to skip everything but leaf level cells, regardless of whether the measure is a value or a string. In order for a cube intersection to be a leaf, every dimension element has to be a leaf. If even a single element is a "C" (meaning consolidated) then having ViewExtractSkipCalcsSet at TRUE will block it from being exported. This function really should be renamed to ViewExtractSkipConsolidatedCellsSet as that better describes what it actually does.

[hyunjia]

There was a bug in this area in either 9.5 or 9.4, specifically to do with exporting string values with one of the options. I can't remember the details but I would recommend that you do some tests.

Create a small test cube with one simple hierarchy and a measure dimension with two string measures. In the rule file leave one of the string measures and calculate the other from the first by appending something. Then enter data for the first measure at all levels of the hierarchy and try out all combinations of settings in the export dialog making sure that what gets exported matches what you expect.

It also helps if, when you are reporting unusual behaviour, you mention the exact version you are seeing it in.

I look forward to hearing your results.

First of all , I didn't say it's a bug , but merely the fact that it behave differently as I expected . Thanks Dungan.P , a really nice approach , I have create a 2 dimension cube and view as illustrated .
Measure
-----------------------------------------------
ConA " "
A A
B B
C C

I enter string value in leaf level , now I build a view that contain only the ConA , which is a consolidate element that included A , B and C . The next step , I right click on the view from server explorer and select "export as text Data" , then select "skip consolidated Values and "skip zero/Blank Value" .

The result , it return nothing in the text file . My original assumption is that it should work as numeric value , where I expect to get all non-blank cell in leaf element level .

So that's why I am so curious about it . If that's the case , which means I have to put more effort and consideration when I try to export those text data from the cube and construct the view more carefully to consider all possible combination and make sure no non-blank string cells are left behind

[hyunjia]

Yes , string value is inputted in leaf level

This is pretty annoying as sometimes user might inputted string value in consolidate element .

Your facts are in direct contradiction. First you say strings are entered at the leaf level and then you say that the supposed "bug" is annoying because users may input at the consolidated level. Which one is it? If you are setting ViewExtractSkipCalcsSet to TRUE then it is going to skip everything but leaf level cells, regardless of whether the measure is a value or a string. In order for a cube intersection to be a leaf, every dimension element has to be a leaf. If even a single element is a "C" (meaning consolidated) then having ViewExtractSkipCalcsSet at TRUE will block it from being exported. This function really should be renamed to ViewExtractSkipConsolidatedCellsSet as that better describes what it actually does.

I am sorry to make this bit confusing . But I am not saying it's a bug but I just feel it doesn't work the way as numeric value do , e.g. skip consolidated value and export only leaf value . Please refer my last reply which illustrate my finding with a test .

My original implementation is to create a view , set ViewExtractSkipCalcsSet = true , then I would get all data from leaf level . In that way , I could ignore cell value from consolidated level( Possiblely entered by mistake ) and save me the effort to create All leaf level subset .

[hyunjia]

There was a bug in this area in either 9.5 or 9.4, specifically to do with exporting string values with one of the options. I can't remember the details but I would recommend that you do some tests.

Create a small test cube with one simple hierarchy and a measure dimension with two string measures. In the rule file leave one of the string measures and calculate the other from the first by appending something. Then enter data for the first measure at all levels of the hierarchy and try out all combinations of settings in the export dialog making sure that what gets exported matches what you expect.

It also helps if, when you are reporting unusual behaviour, you mention the exact version you are seeing it in.

I look forward to hearing your results.

Forgot to mention , I test this both in 10.1.1 and 10.2

[declanr]

First of all , I didn't say it's a bug , but merely the fact that it behave differently as I expected . Thanks Dungan.P , a really nice approach , I have create a 2 dimension cube and view as illustrated .
Measure
-----------------------------------------------
ConA " "
A A
B B
C C

I enter string value in leaf level , now I build a view that contain only the ConA , which is a consolidate element that included A , B and C . The next step , I right click on the view from server explorer and select "export as text Data" , then select "skip consolidated Values and "skip zero/Blank Value" .

The result , it return nothing in the text file . My original assumption is that it should work as numeric value , where I expect to get all non-blank cell in leaf element level .

So that's why I am so curious about it . If that's the case , which means I have to put more effort and consideration when I try to export those text data from the cube and construct the view more carefully to consider all possible combination and make sure no non-blank string cells are left behind

I build a view that contain only the ConA , which is a consolidate element that included A , B and C .

+

then select "skip consolidated Values and "skip zero/Blank Value"

= An output that will ALWAYS return nothing.


By building a view that only contains "ConA" Consolidation in that dimension' subset, you are not creating a view that includes the n-level elements below it. You need to change your subset to include "ConA", "A", "B", and "C"... just selecting the "All" subset will probably do this.

If any single dimension within your cubes view has a subset assigned that only contains consolidated elements, selecting "Skip Zero/Blank Values" will in essence use another subset that contains only the n-level elements in the subsets you started with and in that subset you have zero n-level elements.... as such you are selecting no intersections of the cube to run your query against.