It was reported that the use of single quotes in set analysis for literal values stopped working properly after upgrade to the Sept 2018 version. The set expression with single quotes does not match the textual part of a dual field.
Environment:
QlikView
Qlik Sense Enterprise on Windows
Example to illustrate this issue: Dual field named Flag with textual values Yes, No and numeric value 1, 0.
Set modifier containing this field (for example =sum({$<[Flag]={'Yes'}>}[Count]) ) no longer works and returns zero, instead of the expected value of 2.
Related to this behavior, single quotes should imply a literal match (case sensitive) with the textual component of the dual value. Double quotes ("...",[...], and `...`) should imply a text search (case insensitive) in the textual component of the dual value. In neither case should it be compared with the numeric part of the dual field. The behavior gets more complicated since we have different behaviors for new and old documents which can be adjusted for newer versions of QlikView and Qlik Sense (November 2018 and above) with a change to the settings.ini file Please see the following community post for a more detailed discussion of this topic: Quotes in Set Analysis
You can tweak the behavior by changing the Settings.ini file under the [Settings 7] tag. Introduce the following parameter:
EnableSingleQuoteExactSearch=2
0 = all apps have old behavior
1 = new apps have new behavior, old apps have old behavior (default)
2 = all apps have new behavior
Further. if you have the default EnableSingleQuoteExactSearch=1, then you can force individual documents to behave as old/new documents by adding the below setting as one of the first lines in the script:
///$sqs new
///$sqs old
Resolution:
Fix version:
Qlik Sense April 2019
QlikView 12.40 IR
QlikView 12.30 SR3
Fixed problem with set expression containing single quotes not matching the textual field.
Workaround:
The workaround for this issue is to use double quotes. For the example above:
=sum({$<[Flag]={"Yes"}>}[Count])
The main concern with this workaround is that on a large dataset, search string may be slower (as the engine does have to perform a search) than a direct literal match.
Please check the release notes of future versions when they are released of see if these defects are listed as fixed.
