Escape sequences are a general technique to represent characters that are not possible to represent directly. In QlikView the need is mainly for quotation marks, but in the general case it could also be strange characters, tabs, and newlines. How this is handled in QlikView is explained in this post.
When writing a string in QlikView, it must usually be enclosed in single quotes. But what if you want to use a single quote inside the string? The following will not work:
Setvariable = 'This year's number';
The reason is that the apostrophe in the word year’s will be interpreted as the single quote that ends the string. So what should you do instead?
One solution that I have seen often in the community is to hard-code it using the Chr() function:
Both these work fine, but they are maybe not very elegant. Instead, I would suggest one of the following methods. First, you can often use a different delimiter:
Setvariable = [This year's number];
As you can see, the Set statement can also use square brackets (or double quotes) as delimiters. Hence, if you just use a delimiter that is different from what you have in the string, it will work. The same is true if you need to load from a file with a name that contains single quotes or square brackets. Just make sure you quote it using double quotes (which is a character that shouldn't exist in file names):
Load … From "This year's numbers [3].xlsx"
But there is a second way this problem can be solved. An escape sequence:
Letvariable = 'This year''s number';
The Let statement is different from the Set statement in that you must use single quotes as delimiter for literals. So you need to use an escape sequence instead: Just write the single quote twice, and the two characters will not be interpreted as a string delimiter, but instead as a single instance of the character itself. The same method can be used in other places also, e.g. in Set Analysis. The following expression is a correct one picking out the records from Robert's unit:
Sum({1<Unit={'Robert''s unit'}>} Amount)
An escape sequence can be used for double quotes and square brackets, too. So if you have a field name that contains double quotes, for instance Name”5, you can load it either by using square brackets or by escaping the double quote:
[Name"5]asField1, "Name""5"asField2,
If the field name contains square brackets, e.g. a field called Name[5], only the right bracket needs to be escaped. Such a field can be loaded in either of the two following ways:
"Name[5]"asField1, [Name[5]]]asField2,
With this, I hope you got some ideas about how to deal with odd characters and strangely named fields.
So you are right when it comes to the exact sentence (case sensitive) <<Robert's unit>> but i think that we all should start using double quotes in set analysis as a general rule and only use single quotes when the upper/lower case matters.
To be absolutely clear - it should work like this:
Single quotes in Set Analysis = Case sensitive match with single field value. Wild cards are not possible.
Double quotes in Set Analysis = Search, e.g. a case insensitive wildcard search
The bug is that both types of quotes are today interpreted as (case insensitive) searches where you can use wild cards.
Should you start to always use double quotes? No, not if you want a literal match with a string (no wildcards). Then you can continue to use single quotes.
Typically, when I would like to store a formula in the variable, and make a part of this formula dynamic based on contents of some other variable, or a calculation (the $(=...) type of expansion). Thankfully, this is no issue when assigning the variable contents from an external store (which is the saner option when there is plenty of them, anyway), but it still would be nice to be able to do it cleanly in script
I didn't realise that these days you needed quotes on the right hand side of a SET statement? What's wrong with
SET variable = This year's number;
The only thing I can see that may be 'unwanted' is that making use of its unquoted value may push you towards $-sign substitution instead of just dropping in the variable name.
Normally you don't need to quote in a Set statement. But in this case you do. Otherwise the parser gets lost when it encounters the single quote. Try it, and you'll see that the variable value contains a lot more than you want...