Skip to main content
Announcements
Join us at Qlik Connect for 3 magical days of learning, networking,and inspiration! REGISTER TODAY and save!
cancel
Showing results for 
Search instead for 
Did you mean: 
Flo_Kopp
Partner - Contributor II
Partner - Contributor II

Set Analysis '=' vs 'like'

Hi there,

im facing a Problem that has already been mentioned a few years ago. Im Using Set Analysis on a field that can have values like 'kk' or 'KK' that have a different meaning ( illness reasons for employees). 

i used this expression on a specific date:

sum( {< %codeday={'kk'}>} days.noofdays)

 even tho the employee has no entry for the combination of %codeday = 'kk' on this day i get 1 as result. The employee has an entry for 'KK' on that day.

So it seems like Qlik Sense is not using = but like in this expression.

Can anyone confirm this behaviour? Is there a possibility to solve this problem within an set expression? My thought was now to flag all uppercase entrys within the Backend to be able to use this as additional modifier.

 

thanks in advance

Florian

 

Labels (1)
3 Replies
marcus_sommer

AFAIK it should work case-sensitive. At least in View it does and AFAIK there should no difference between them in the last releases. Are you really using %codeday={'kk'}  or is it %codeday={"kk"} ?

- Marcus

Flo_Kopp
Partner - Contributor II
Partner - Contributor II
Author

Hi there,

yes i am sure. heres a Screenshot figuring the problem:

Flo_Kopp_0-1614950952957.png

Using Qlik Sense 14.5.4 (February 2021)

marcus_sommer

IMO that shouldn't happens. Please take a look on the last release notes if there were any changes to the set analysis especially regarding the quoteology there. In the early releases of set analysis there were some bugs about it and AFAIK it was corrected within QV 12 and probably similar in Sense whereby they created a special setting for it so the user could choose if he wants to use the old or new syntax/logic or a mix of it. AFAIK some releases later they removed this special setting because it was only aimed to ease the transition. Maybe it's back in some way and/or related to other parsing-settings like collation.

Beside this you could try one or the other different syntax like "'KK'" or 'kK' or (KK) and if none worked you may use an expression like: index(Field, 'KK'). Like you already mentioned you may also make some adjustments to your script and extra flagging the lower/upper case and/or creating dual() values for them.

- Marcus