Qlik Community

QlikView Layout & Visualizations

Discussion Board for collaboration on QlikView Layout & Visualizations.

Announcements
Qlik Analytics Tour 2020 Online. Begins August 10th. Register Today
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
MVP & Luminary
MVP & Luminary

Pivot didn't keep the expanding state of columns

Hello,

I have the strange issue that a particular pivot-table didn't keep their last expanding state of their columns by opening the application within the desktop client (QV 11.2 SR12) - it always changed to a different appearance as it was stored and the change is always the same. The pivot contained two dimensions and 4 of the 14 dimensions-values are expanded and two of the expanded dimension-values do change (there are 13 expressions - just simple sums with different set analysis time-ranges and there are always data available).

After a reload the pivot restore the saved expanding state and the pivot looked like expected. The application is quite new - a new realese of an older one - and also the pivot-table was newly created. Nevertheless I created again a complete new pivot and got the same behavoiur. I also copied the pivot from the old application and they also failed.

Within the AJAX client everything worked fine but within the desktop client it didn't. Nevertheless I removed the shared- and the meta-file but the problem remained. Then I disabled the section access (the same like in the old application) and the pivot started working again - this meant there is anywhere a dependency between the pivot expanding state and the section access (which is just a restriction to a field and no restrictions to sheets or objects) and the applied data-reduction - but why?

Has anyone an idea how to overcome this problem?

- Marcus

5 Replies
Highlighted
MVP & Luminary
MVP & Luminary

Re: Pivot didn't keep the expanding state of columns

No one experienced ever a similar case or could think of a possible relation between the expanding state of a pivot and the section access data-reduction?

- Marcus

Highlighted
MVP
MVP

Re: Pivot didn't keep the expanding state of columns

I have not seen this myself, but a wild guess - something to do with suppressing zeros/nulls??

Logic will get you from a to b. Imagination will take you everywhere. - A Einstein
Highlighted
MVP & Luminary
MVP & Luminary

Re: Pivot didn't keep the expanding state of columns

It seems that you are right about the NULL. I had enabled the hiding of NULL's within the first dimension but just disabling it didn't work - after removing the NULL's from the datamodel the pivot didn't change anymore by opening or reloading.

Nevertheless the question - why did it behave like it does? Especially by disabling the section access it worked like expected though NULL's within this dimension was available and by either with hiding or without hiding them.

Beside them I have tried to remove any possible data-reduction within the section access. All tables have now the same number of records by opening the application and after a reload (for me as admin) but still any data-reduction seems to be applied because I couldn't just store the application after opening them without overwriting it or to do a reload.

Could anyone shed some light into the matter?

- Marcus

Highlighted
MVP & Luminary
MVP & Luminary

Re: Pivot didn't keep the expanding state of columns

To conclude this topic I must admit that the behaviour of pivot expanding/collapsing is for me quite buggy. It seems now solved and stable after I replaced the calculated dimension within the first dimension (only a few simple if's to exclude, rename and group some of dimension-values) with a real dimension created in the script and removing of all dimension-values of the second dimension which reside in the collapsed area.

In my opinion there shouldn't be dependencies between section access, NULL handling options and calculated dimensions regarding to the expanding/collapsing feature of a pivot ...

- Marcus

Highlighted
Contributor II
Contributor II

Re: Pivot didn't keep the expanding state of columns

I think this is related to a changing order in the data source. See this: https://support.qlik.com/articles/000038678