Skip to main content
Announcements
Introducing Qlik Answers: A plug-and-play, Generative AI powered RAG solution. READ ALL ABOUT IT!
cancel
Showing results for 
Search instead for 
Did you mean: 
james_daly
Contributor
Contributor

Table: Include null values

I have found some strange behaviour for the Table Chart in QlikSense, which I beleive is a bug.

If I deselect the "Include null values" option on a key field, it removes records that have a value but are not in all the tables that share that key field.

What are your thoughts?

Example:

If you add all the fields into a Table Chart and deselect the "Include null values" option on the ID field, only the records for ID=A and ID=C will remain.

The record for the extra Type and Column (Car, Thing) will correctly be removed, since there is no record in the Records table that has the matching value in Type. However, the record where ID=B is also removed.

The only explanation I can come up with is that there is no record in the DB table where ID=B.

Load Script:

Records:
LOAD * INLINE
[
    ID, Name, Type
    A, Apple, Fruit
    B, Banana, Fruit
    C, Cabbage, Vegetable
];

DB:
LOAD * INLINE
[
    ID, Record
    A, five
    C, seven
];

Types:
LOAD * INLINE
[
    Type, Category
    Fruit, Food
    Vegetable, Food
    Car, Things
];

 

Labels (1)
1 Solution

Accepted Solutions
marcus_sommer

Your observed behaviour is related to the fact that the field ID is a key-field and therefore they don't belong to a single table else at least to two tables. And in this case are for ID only two values common in the associated tables and the third one from the Records is pointing against NOTHING and is therefore hidden by enabling the hide-option.

It's not a special Sense behaviour else it's the same in QlikView since ever (at least for a long time). Within the most scenarios this kind of behaviour of using key-fields within the UI dimensions/expressions won't be noticed respectively not regarded as an unexpected behaviour but I could remember an old officially suggestion not to use key-fields within the UI.

Like hinted unexpected results are rather seldom and if they occur you could bypass them just by duplicating the field. In this case within the load of Records, for example as ID2 and if you then enables the hide-options for this field you should get your wanted view.

View solution in original post

4 Replies
Chanty4u
MVP
MVP

May be this is the reason

the association between the "Records" table and the "DB" table is based on the ID field. When you deselect the "Include null values" option on the ID field, it is possible that the record for ID=B is being removed because there is no corresponding record in the "DB" table where ID=B exists.

james_daly
Contributor
Contributor
Author

That is my thoughts as well, but I can't think of a reason why that would be the desired outcome.

marcus_sommer

Your observed behaviour is related to the fact that the field ID is a key-field and therefore they don't belong to a single table else at least to two tables. And in this case are for ID only two values common in the associated tables and the third one from the Records is pointing against NOTHING and is therefore hidden by enabling the hide-option.

It's not a special Sense behaviour else it's the same in QlikView since ever (at least for a long time). Within the most scenarios this kind of behaviour of using key-fields within the UI dimensions/expressions won't be noticed respectively not regarded as an unexpected behaviour but I could remember an old officially suggestion not to use key-fields within the UI.

Like hinted unexpected results are rather seldom and if they occur you could bypass them just by duplicating the field. In this case within the load of Records, for example as ID2 and if you then enables the hide-options for this field you should get your wanted view.

james_daly
Contributor
Contributor
Author

I agree on the not using Key Fields in the UI. I only discovered this issue when a self-service user asked about it in an app they made for their personal use.

That also probably explains why I never saw it in QlikView either.