What’s the difference between Peek() and Previous() in Qlik Sense?

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 the difference between Peek() and Previous() in Qlik Sense and QlikView:

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:

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.

How the Previous() function works

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. The second row is empty. 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. There is nothing on that row:

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.

How the Peek() function works

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:

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?

More from the Bitmetric team

Qlik Cloud Backup

Protect your investment in Qlik with daily incremental backups stored in an encrypted environment with redundant storage. Available for as little as 2 Euro per day. Learn more.

Join the team!

Do you want to work within a highly-skilled, informal team where craftsmanship, ingenuity, knowledge sharing and personal development are valued and encouraged? Check out our job openings.