Today, the Qlik engine has some bugs in the area of a search and a subsequent select. These affect both interactive searches and searches in Set Analysis expressions. We are working on fixing them. However, one of these coming bug fixes may cause some backward incompatibility. This post explains what the bug fix will mean, and what you can do to avoid future problems.
When you use Set analysis, you can choose to have a condition in the form of a list of values in the Set expression, or you can choose to have a rule-based definition - a search for field values.
All the above constructions work today, and they will work correctly also after the bug fix.
Note the double quotes in the search expressions. These define the search strings, and between them you can write any search string – the same way as you would in a list box search.
However, you should not use single quotes to define a search string.
Single quotes are reserved for literals, i.e. exact matches. Hence they should be used when you want to make a list of valid field values, like the above list of explicit countries. But they should not be used for searches. Single quotes imply a case sensitive match with a single field value.
This difference between single and double quotes has been correctly described in the reference manual that states that searches are “always defined by the use of double quotes”. Also, all examples with literal field values in the documentation use single quotes.
Now to the bug: QlikView and Qlik Sense currently do not respect the above difference between single and double quotes. Instead, strings enclosed in single quotes are interpreted as search strings. As a consequence, it is not possible to make case sensitive matches with field values, something which you sometimes want to do.
This bug will be fixed in the coming November releases of Qlik Sense and QlikView. Then, wildcards in strings enclosed by single quotes will no longer be considered as wildcards. Instead, the strings will be interpreted as literals, i.e. the engine will try to match the string with a field value containing the ‘*’ character. The same logic will apply also to relational operators and equals signs.
Unfortunately, this bug has been incorrectly utilized by some developers: I have seen Set Analysis expressions with correct search strings, but erroneously enclosed in single quotes; for example
Sum( {$<Country = {'Austr*'}>} Sales)
This search should instead have been written
Sum( {$<Country = {"Austr*"}>} Sales)
Hence, there are documents with expressions that will not work in the corrected algorithm. However, the bug fix will be implemented in such a way that old documents will use the old logic, and new documents will use the new logic. In addition, it will be possible to force the new logic for all documents by using a parameter in Settings.ini.
You can of course also change the single quotes in existing search strings to double quotes, and the expression will continue to do what it always has done.
This post is mainly to give you a heads-up on a coming change, and give you a chance to make a quality control of your own documents. We will publish more information as we get closer to the release.
Re the variable expansion (even though a bit off topic for this thread). I too am surprised that there could be a difference between desktop and server, but the rest of it makes perfect sense to me. .
Evan showed his variable definition as:
vColor = RGB(100,255,100);
which is equivalent to:
LET vColor = RGB(100,255,100);
The result would be a dual; string value of "RGB(100,255,100)" and numeric value a proper 32 bit color number.
So a direct reference of vColor would work because it would retrieve the color number. A reference of $(vColor) will also work regardless of whether the string or numeric value is expanded, because the expression will be evaluated after the expansion, yielding the 32 bit number.
If the color variable was defined with SET, the $() would be required.
*Reloading the attached application allows the effect to be repeated
Two color variables are being created in script, and they work fine.. UNTIL they are "touched" in an input box expression area.
Then once the mouse focus leaves the input box and clicks somewhere else on the application, the variable behavior changes, and the color expressions detach. (The reason this appears so strange, is the definition of the variable itself is not altered, but obviously some other hidden property is in motion, merely by entering/exiting the edit window)
So trying to pin down the 'where' of the effect was misleading. If a user touches the variables on desktop, the breakage is visible on desktop. If the variables were "touched" on the server, it makes it appear as breakage originates on server.
***Addendum: Performing an A/B comparison of the .QVW project export pre/post effect is not producing any observable difference. Performing a WinMerge diff on the pre/post .QVW triggered the following alert, but no immediately obvious change visible in the XML portions of the .QVW
Do we have a release date for Qlikview 12.20, we would like to prepare our teams ready to get our testing completed on the full release ready to move onto our live servers.
The new rule applies only when you create a new document in the Nov release. Is this a new qvw you are testing with, or a qvw created in a prior release?
.png "Former Employee"){kind=icon}