QlikFix

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:

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:

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:

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.