Bitmetric Friday Qlik Test Prep – Week 17 – Peek() vs Previous()

By Bitmetric Admin

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:

Geen alternatieve tekst opgegeven voor deze afbeelding

The correct answer is B: Peek()

Since none of the answers provided a “fix it in the source” we are left with Peek() as the best solution for this problem. The main difference in these answers is that Peek() will look at the output table whereas Previous() will evaluate the input table. So if we compare those two answers we find that Previous() is not giving us the result we would like:

Geen alternatieve tekst opgegeven voor deze afbeelding

We see that not all OrderID’s are correctly populated by using Previous(). This is due to the fact that Previous() will evaluate the input table, while Peek() will evaluate the output table.

Looking at the visualization below we can see why this happens. For the first row Previous() will return NULL. This is always the case for the first row in Previous() since there is nothing to evaluate. Then the second row is empty and since we specified that empty rows should be evaluated, we receive the previous row from the input table, being OrderID 5586. Moving on to row number three, we find this row to be empty again. So the same statement is triggered. However, since we are looking at the input table, we will receive an empty value, since there is nothing on that row:

Geen alternatieve tekst opgegeven voor deze afbeelding

As we can see this gives us the problem of still having empty OrderID’s in the final table. For every empty row after an empty value, we will receive nothing.

Peek() however, evaluates the output table. The statement in answer B tells Qlik that if a row for OrderID is empty to use Peek(), which reads the last read record for OrderID, and use that. Since we are now looking at the output table instead of the input table, we can see what this does to the results:

Geen alternatieve tekst opgegeven voor deze afbeelding

On the second row we evaluate the last read record using Peek() and it is populated straight away. Now moving on to the third row (which is still empty at that point), it will do the same thing again. Looking at the last read record. And contrary to Previous() where the source table was still empty for the second row, it is now populated, because the previous row has been filled by peek. So we can find the correct OrderID. 

 That’s it for this week. See you next Friday? And remember:

  • If you have suggestions for questions, we love to hear from you via WhatsApp or at [email protected]
  • If you’re enjoying these questions and want to work on stuff like this every day (but a bit more challenging), we’re always on the lookout for new colleagues. Check our job openings here.

Previous posts

Week 16: SubField()

Week 15: FirstSortedValue()

Week 14: Date() vs Date#()

Week 13: Set Analysis – Literal vs Search Strings

Week 12: Automatic Concatenation

Week 11: Sum(TOTAL)

Week 10: Unpivoting data

Week 9: Statements & Breakpoints

Week 8: Sales & Budget model

Week 7: MonthEnd(Today())

Week 6: Looping Tables

Week 5: Set Identifiers

Week 4: Time series visualization

Week 3: Circular References & Synthetic Keys

Week 2: Section Access

Week 1: Optimized Load