Why Qlikview wont let me change my selection

[#1]

Please see the attached Qlikview. I have changed fields to reduce the problem to few tables and generic names.

Click the button (note its Actions will affect a selection).

Once the selection happens, you can't change from 2012-12-31 to 2013-12-31.  

I explained it further in the Qlikview, but you can also see details below:

Thoughts?

DetailData:

LOAD * INLINE [

    DetailDescription, DetailId, Joiner

    not this thing, 1, 21000-12/31/2014

    not this thing, 2, 0-12/31/2014

    not this thing, 3, 16951-12/31/2013

    why is this screwed, 4, 0-12/31/2013

    want this thing, 5, 15209-12/31/2012

    want this thing, 6-ignore, 0-12/31/2012

    want this thing, 7, 16951-12/31/2013

    want this thing, 8-ignore, 0-12/31/2013

];

TopLevelData:

LOAD * INLINE [

    Year, Joiner

    2012-12-31, 15209-12/31/2012

    2012-12-31, 0-12/31/2012

    2013-12-31, 16951-12/31/2013

    2013-12-31, 16157-12/31/2013

    2013-12-31, 0-12/31/2013

    2014-12-31, 21000-12/31/2014

    2014-12-31, 0-12/31/2014

];

CouldDropThisTableThatWouldFix:

LOAD * INLINE [

    SourceFile, Year

    a, 2012-12-31

    b, 2013-12-31

    c, 2014-12-31

];

While the button unlocks, clears all, and enacts this selection as my starting point:

• Select in Field; DetailId = (5)
• Select in Field; Year = 2012-12-31
• Select in Field; DetailDescription = *want*
• Lock Field; DetailDescription

And from that point, Qlikview won't allow me to change my expression to 2013-12-31...

After clicking the button,  now try to click 2013-12-31. It won't allow your selection to change.

I understand that DetailId of 5 doesn't exist in 2013-12-31...  But I haven't locked DetailId field;

My expectation: Qlikview allows you to click 2013-12-31; and would automatically clear or change the DetailId selection accordingly.

It does allow your selection to change if any of these conditions were met:

• DetailDescription search string was '*thing*' instead of '*want*'
  • I guess because it stretches DetailDescription to something else which exists in 2013-12-31
  • Note this starting point would expect as I behave; changing to 2013-12-31 does just clear the DetailId selection
• DetailId search string was '(5|7)' instead of '(5)'
  • I guess because 7 exists in the 2013-12-31, the new selection would not be mutually exclusive
• Dropped the third table CouldDropThisTableThatWouldFix; see load script
  • I have no idea why this helps

[rwunderlich]

When a field is locked, QV will not allow a selection of any value (regardless of the field)  that is not associated with the locked selection(s). This is by design.

You statement is correct at the end of your post where you surmise:

It does allow your selection to change if any of these conditions were met:

• DetailDescription search string was '*thing*' instead of '*want*'
  • I guess because it stretches DetailDescription to something else which exists in 2013-12-31

-Rob

http://masterssummit.com

http://qlikviewcookbook.com

[#3]

Thank you, Rob.

So the locked field is part of the cause -- indeed if I unlocked that field, that is another way of getting my expected behavior on changing selection.

So here is my selection, note nothing is locked.

FIELD	VALUE
DetailDescription	*want*
DetailId	(5)
Year	2012-12-31

Then I click 2013-12-31, now this is my selection:

FIELD	VALUE
Year	2013-12-31

Which I find odd, why couldn't *want* stay in the selection?

I guess that is a different question altogether, understanding how the selection works without the lock... Anyway:

You emphasize one of my guesses:

• I guess because it stretches DetailDescription to something else which exists in 2013-12-31

But when I print a straight table with the data... I can find a "want this thing" in 2013-12-31... (Therefore I now think my guess was a mistake... or I stated it wrongly...)

"*thing*" is only different than "*want*" , it seems, because it ...

• has 2014-12-31 for Year
  • And indeed if I delete these rows from the table, that is yet another unexpected way to get my selection working as expected
    
• and a new "c" SourceFile
  • (I still don't understand how this extra table affects things; and why dropping it is a fix.)
• and some new [irrelevant? due to the "(5)" filter?] DetailIds

DetailDescription	DetailId	Joiner	SourceFile	Year
not this thing	1	21000-12/31/2014	c	2014-12-31
not this thing	2	0-12/31/2014	c	2014-12-31
not this thing	3	16951-12/31/2013	b	2013-12-31
want this thing	8-ignore	0-12/31/2013	b	2013-12-31
want this thing	6-ignore	0-12/31/2012	a	2012-12-31
want this thing	5	15209-12/31/2012	a	2012-12-31
want this thing	7	16951-12/31/2013	b	2013-12-31
why is this screwed	4	0-12/31/2013	b	2013-12-31
		16157-12/31/2013	b	2013-12-31

Moreover, "*thing*":

• Seems to have equal claim to the DetailId of (5), as does "*want*" :
  • (5)'s DetailDescription satisfies both "*thing*" and "*want*";
  • and both "*thing*" and "*want*" appear on non-5 rows.
• When I repeat the above selection experiment (i.e. without any locks), using "*thing*" instead of "*want*", the ending selection is exactly the same:

  FIELD	VALUE
  Year	2013-12-31

And I still don't understand how an extra SourceFile/table is relevant...

Am I overthinking this? Probably.

Thanks for your advice.

[#4]

To be clear, I think I do understand what you're saying here, but please tell me if I'm wrong.

When you say:

When a field is locked, QV will not allow a selection of any value (regardless of the field)  that is not associatedwith the locked selection(s). This is by design.

That means in this case of data:

[ Fruit, Color

Apple, Red

Raspberry, Red

Blueberry, Blue

Banana, Yellow ];

If I lock Fruit = *berry* , I can't select Color=Yellow (though I can select Red or Blue.)

And if I lock Color = Red, I can't select Fruit=Blueberry (though I can select Raspberry or Apple)

Do I understand you correctly? I should test and see...

Even if I am right, I can't quite see how my data fits this pattern, as I discussed in my initial reply to your answer. Can you help me see that?