Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hello everyone!
Our team found a big issue in Qlik Sense May Patch 4. I created test script for data generation:
SET ThousandSep=',';
SET DecimalSep='.';
SET MoneyThousandSep=',';
SET MoneyDecimalSep='.';
SET MoneyFormat='$#,##0.00;-$#,##0.00';
SET TimeFormat='h:mm:ss TT';
SET DateFormat='DD.MM.YYYY';
SET TimestampFormat='DD.MM.YYYY h:mm:ss[.fff] TT';
SET FirstWeekDay=6;
SET BrokenWeeks=1;
SET ReferenceDay=0;
SET FirstMonthOfYear=1;
SET CollationLocale='en-US';
SET CreateSearchIndexOnReload=1;
SET MonthNames='Jan;Feb;Mar;Apr;May;Jun;Jul;Aug;Sep;Oct;Nov;Dec';
SET LongMonthNames='January;February;March;April;May;June;July;August;September;October;November;December';
SET DayNames='Mon;Tue;Wed;Thu;Fri;Sat;Sun';
SET LongDayNames='Monday;Tuesday;Wednesday;Thursday;Friday;Saturday;Sunday';
SET NumericalAbbreviation='3:k;6:M;9:G;12:T;15:P;18:E;21:Z;24:Y;-3:m;-6:μ;-9:n;-12:p;-15:f;-18:a;-21:z;-24:y';
Characters:
Load Chr(RecNo()+Ord('A')-1) as Alpha, RecNo() as Num autogenerate 26;
ASCII:
Load
if(RecNo()>=65 and RecNo()<=90,RecNo()-64) as Num,
Chr(RecNo()) as AsciiAlpha,
RecNo() as AsciiNum
autogenerate 255
Where (RecNo()>=32 and RecNo()<=126) or RecNo()>=160 ;
Transactions:
Load
TransLineID,
TransID,
mod(TransID,26)+1 as Num,
Pick(Ceil(3*Rand1),'A','B','C') as Dim1,
Pick(Ceil(6*Rand1),'a','b','c','d','e','f') as Dim2,
Pick(Ceil(3*Rand()),'X','Y','Z') as Dim3,
Round(1000*Rand()*Rand()*Rand1) as Expression1,
Round( 10*Rand()*Rand()*Rand1) as Expression2,
Round(Rand()*Rand1,0.00001) as Expression3;
Load
Rand() as Rand1,
IterNo() as TransLineID,
RecNo() as TransID
Autogenerate 1000
While Rand()<=0.5 or IterNo()=1;
Comment Field Dim1 With "This is a field comment";
After I created 3 measures that you can see in the picture. Last expression has wrong Set Analysis. Early Qlik Sense version was showing error but now current version shows wrong result.
Expression says all is good:
Why?
I think it's a really nasty bug. Imagine using a field in the model and using that in your Set Analysis. Then the field disappears from the model. For example, you rewrite the load statement without that field and forget that you also use that field in one of your expressions. You shouldn't remember it after all. So you will get a wrong calculation in the chart, as there is no field filter in the set analysis at all. Better if set analysis in that case gives null result 'cause null draws attention that something is wrong.
I suggest that instead of changing the set analysis engine, developers should be given reminders or hints, as was the case in the previous version. Why not?
Further, give us a check-list somewhere in the UI of QS to check off if we've used the fields which are absent in the model in the charts. It may be some kind of an API call.
P.S. I also had this happen when this bug, err... feature hit us in QV - NP combination during a monthly report emailing. It was awkward... and you know )))