Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

Announcements
Save $650 on Qlik Connect, Dec 1 - 7, our lowest price of the year. Register with code CYBERWEEK: Register
cancel
Showing results for 
Search instead for 
Did you mean: 
levente81
Partner - Contributor III
Partner - Contributor III

Same field shows different value in 2 charts

Hi,

I am facing an exciting enigma in Qlik, and I hope someone can advise a solution / workaround.

I have a field with lots of values that I categorize into 5 buckets with using simply nested if statements  - dual() values assigned for those groups.

Then I am expected to use this data in a pivot chart where the main dimension is a valuelist() and the sub dimension is one of 3 bucket fields depending on the valuelist() dimension's value.

It worked good, when I created the logic several weeks ago and now I got a complaint that something was wrong with this pivot table - for some reason one of the bucket fields are not properly displayed => the "label" part of the dual value is not properly displayed: dual('0',1) is displayed as 1, next bucket is dual('1',2), then dual('range1',3) etc.

If I use the same field and filter the "parent" field to 0 where the bucket value shall be this dual('0',1) then I get the proper 0 displayed, while pivot remains corrupted...

Do you have any idea, workaround for such bug?

Thanks and best regards,

Levente

Labels (1)
1 Solution

Accepted Solutions
levente81
Partner - Contributor III
Partner - Contributor III
Author

It was a temporary bug - it got solved without any modification.

View solution in original post

5 Replies
Oleg_Troyansky
Partner Ambassador/MVP
Partner Ambassador/MVP

It's really difficult to guess what might be wrong there. If you can, post a sample app that shows this behavior.

Ask me about Qlik Sense Expert Class!
marcus_sommer

I don't think that there is any bug else that the data have changed and aren't unique anymore - in regard to the applied dual(). This means it's quite likely that there are now multiple string-values for the same numeric value.

Beside this I suggest to replace the valuelist() with the field-values from an island-table. It wouldn't only simplify the chart-dimension else even more the expressions and an island-table mustn't be just a single field else it might be several ones with a grouping and extra information. Further such native fields could now be used within TOTAL statements and/or aggr() constructs. Probably there are some more benefits ...

levente81
Partner - Contributor III
Partner - Contributor III
Author

levente81_0-1692276468103.png

Hi Marcus,

I do not think it is a data update issue that certain dimension is displayed:

- properly in a filter pane

- erroneously in a pivot table

at the same time...

If plain field value is 0 then bucket field value is dual('0',1)

If plain field value is 1 then bucket field value is dual('1',2)

... this logic is used to create in DLE the bucket field that is displayed erroneously in pivot table.  I see no reasonable situation where such expression shall result dual('1',2) - please check the screenshot: I have a filter on the plain field...

marcus_sommer

That's not mandatory the same because the filter pane showed only distinct values  from a single field against a certain state while the pivot may enforce a cartesian view and consider multiple states - and both may also have different sorting-options.

Further both types of objects are limited to the capability to show all field-values and their relationship against each other. More suitable would be to use a table-box which also includes unique ID's from all related tables. If none exists they could be created with recno() and/or rowno(). Because of the fact that you are dealing with dual() you may further add a table-chart to be able to query the dual-fields with num() and text() on the lowest granularity and maybe also with count() and concat() on any higher views.

levente81
Partner - Contributor III
Partner - Contributor III
Author

It was a temporary bug - it got solved without any modification.