Qlik Community

Ask a Question

Qlik Design Blog

All about product and Qlik solutions: scripting, data modeling, visual design, extensions, best practices, etc.

Announcements
Support Cases coming to Qlik Community Oct. 4! Start chats, open cases, explore resources. Prep for the big move: READ DETAILS
Henric_Cronström

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:

 

     Set variable = '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:

 

Let variable = 'This year' & Chr(39) & 's number' ;
Let variable = Replace( 'This year#s number', '#', Chr(39) ) ;

 

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:

 

Set variable = [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):

 

LoadFrom "This year's numbers [3].xlsx"

 

But there is a second way this problem can be solved. An escape sequence:

 

Let variable = '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] as Field1,
"Name""5" as Field2,

 

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]" as Field1,
[Name[5]]] as Field2,

 

With this, I hope you got some ideas about how to deal with odd characters and strangely named fields.

 

HIC

 

Further reading related to this topic:

QlikView Quoteology

22 Comments
blaise
Partner
Partner

I recall you saying @qonnections2015 that single quotes in Set Analysis is a "bug" and double quotes should be used instead.

0 Likes
10,876 Views
richard_pearce6
Luminary Alumni
Luminary Alumni

I thought that bug was just when you're doing search type arguments in Set Analysis?

0 Likes
10,876 Views
blaise
Partner
Partner

See HIC's reply in the following thread;

QlikView Quoteology

Capture.PNG

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.

0 Likes
10,876 Views
Henric_Cronström

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.

HIC

10,876 Views
kuba_michalik
Partner
Partner

Is there maybe an elegant method to escape $(), so it's possible to avoid macro expansion at variable assignment time?

0 Likes
10,876 Views
Henric_Cronström

No, unfortunately not. You will have to use one of the non-elegant methods...

But when would you need it? I can only think of a case where you use an equal sign to make the variable dynamic, e.g.

     Let variable = '=$(otherVariable)';

and here you don't need the dollar expansion. You can write this as

     Let variable = '=otherVariable';

HIC

10,876 Views
kuba_michalik
Partner
Partner

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

0 Likes
7,711 Views
Peter_Cammaert
Partner
Partner

There is a method that is a bit more elegant than the default ones:

LET vVariable = 'Keep for 2nd stage expansion $' & '(vStuff)';

0 Likes
7,711 Views
Peter_Cammaert
Partner
Partner

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.

0 Likes
7,711 Views
Henric_Cronström

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...

HIC

7,711 Views