Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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
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
I have not seen this myself, but a wild guess - something to do with suppressing zeros/nulls??
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
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
I think this is related to a changing order in the data source. See this: https://support.qlik.com/articles/000038678