The Qlik debugger, breakpoints, comments and statements

Every Friday at Bitmetric we’re posting a new Qlik certification practice question to our LinkedIn company page. Last Friday we asked the following Qlik Data Architect certification practice question about debugger in Qlik Sense and QlikView, and how to set breakpoints on statements:

Most people who replied had the wrong answer. This is very likely caused because a very important detail was omitted in the phrasing of the question. This wasn’t intentional, just hastily written. Sorry! What we should’ve asked is:

“A Data Architect wants to use the debugger to set a breakpoint on a comment. Which format should be used to ensure that the debugger actually pauses on the comment?“

Does this rephrasing change the answer you would’ve given? And is it the correct answer? Let’s see:

The correct answer is C: REM Breakpoint;

At the heart of this question are three things that you need to be aware of:

1. Qlik Sense and QlikView come with a built-in debugger.
2. Breakpoints in the debugger can only be set on a statement, not on a comment.
3. The REM statement can be used to insert comments into the script.

Let’s look into these a little more.

Qlik Sense and QlikView come with a built-in debugger

A debugger is a tool that lets you test and debug your programs by letting you inspect the flow and state of your program while it is running. Debuggers are available for almost every programming language, often included as part of an IDE.

Both Qlik Sense and QlikView come equipped with a built-in debugger. In Qlik Sense it can be found here in the Data load editor:

In QlikView it can be found here in the Script editor:

Features included in both debuggers are:

• Limited load, the option to only read a limited number of rows in LOAD statements. When dealing with large data volumes this can make test-runs much quicker as only a subset of the data will be loaded (typically 100 or 1000 rows). While convenient, a Limited load can also introduce errors because of non-matching data. We’ll cover this (and the debugger) in more detail another time.
• Step-through, executing the script one statement at a time, pausing after every statement. This gives you the opportunity to see which branches in the code are being executed (in the case of conditional logic) and also which values the variables hold at that particular step in the script.
• Breakpoints, places in the script where the script will be intentionally paused so that we can inspect the current state. Breakpoints are denoted by a dot next to the line number in the script:

Breakpoints in the debugger can only be set on a statement, not on a comment.

In Qlik Sense, a breakpoint is set by clicking next to the line number in the Data load editor. In QlikView, this is done by clicking next to the line number in the Debugger window.

As you can see in the animation above, Qlik let’s you set breakpoints wherever you want. Comments, statements, functions, white space, it doesn’t matter.

Except it does!

When using the debugger, the script will only be paused on breakpoints that are set on a script statement. To illustrate:

In the animation above, we’ve set breakpoints on line 1, 3, 5 and 7. When we run the script, in the debugger, we see that the breakpoints on lines 1 and 3 are skipped. This is because they do not contain a script statement and are therefore ignored by the debugger.

The REM statement can be used to insert comments into the script.

Line 5 contains a script statement (REM) so that’s why the debugger pauses there.

Wait a minute! The debugger also pauses on line 7!

The keen observer will note that the debugger also pauses on line 7. This is because Qlik doesn’t recognize — Breakpoint, assumes it’s a unknown statement and pauses. As — Breakpoint isn’t a valid Qlik statement, the script breaks when we resume the execution.

That being said, the debugger does pause on — Breakpoint so those of you who picked answer D are technically correct. Some say this is the best kind of correct, though it’ll probably not get you any certifications 😉

So REM is only useful to set a breakpoint in the debugger? Boring! I’ll just use // and /* */

Setting breakpoints on comments is probably not an everyday requirement, but there is a place where REM is superior to // and /* */ : to remove entire statements.

REM removes everything until it finds a semicolon. This means that you can use it to remove entire statements with a single comment. For example, the REM statement on line 2 in the image below comments out all the code up to and included the semicolon on line 13.

Compared to the alternatives (see below), it’s a bit faster to write, though arguably harder to read as REM doesn’t seem to be a commonly used statement.

Anyway, there you have it, an answer that’s quite a bit longer than it needed to be to a question that probably should’ve been a bit more verbose 😉

We look forward to seeing your comments and hope to see you again next Friday!

More from the Bitmetric team