IMO, it is a QlikBug (in QlikView 10 & 11) that the QlikView Script engine and editor both attempt to treat the single-quote character as a string delimiter even in contexts where it doesn't make sense i.e. contexts that do not take an expression. Two particular such contexts in which I have had to struggle with this issue are the TRACE and EXEC statements. So, for example:
SUB print(p) trace $(p); ENDSUB
LET vFilename='May'&chr(39)&'04.csv'; TRACE vFilename=$(vFilename); CALL print((3.14)); // this does not get executed TRACE ';
CALL print((2.71)); // this does get executed
The TRACE statement does not take an expression, and yet QlikView trips-up on this sample. Having substituted in vFilename's value and discovered the single quote character, it treats it as the opening delimiter of a string and proceeds to gobble-up all subsequent script until it finds another single quote i.e. in the next TRACE statement. Consequently, the first CALL becomes part of the first TRACE statement's text (and therefore is outputted and not executed), and the second CALL gets executed.
A slightly more exciting example is this:
TRACE vFilename=$(vFilename); CALL print(';abc');
Here, "CALL print(';" is treated as part of the TRACE statement, and QV attempts to treat "abc')" as a separate statement - and, failing, crashes-out of the script.
Has anyone else felt the pain? Is this a bug? Would it break anything if the script engine was smarter about this? And what other statements are contexts where expressions are not parsed and therefore quotes shouldn't be either?
