A paradox development is that we often spend more time troubleshooting QlikView applications than we do developing them. Such is the case that if nobody complains about an incorrect calculation or missing data, then they probably aren't using what we've created. When we become aware of a potential problem, we also tend to invest more time understanding and searching for the anomaly than we do fixing it. Even though this is time well spent when we encounter an issue for the first time, we should avoid repeating the same investigation every time the same issue reoccurs.
In this chapter, we are going to review several common anomalies that occur when we perform data analysis and visualization in QlikView. We document their possible causes and solutions as we would in a knowledge base that we create to help save time when we come across the same issues in the future. Let's cover the following topics to improve our QlikView troubleshooting skills:
- Troubleshooting preparation and resources
- Reporting issues
- Common data model issues
- Common expression issues
First, let's go over the general approach that we take when troubleshooting in QlikView and what resources are available to make it easier.
If we want to create successful QlikView applications, then we have to be prepared to maintain them for many years to come or transfer our knowledge to another person. In reality, we never completely finish great QlikView applications and we continuously transform them when new business questions arise. The troubleshooting, maintenance, corrections, and adjustments that we perform after the initial development is also an excellent opportunity to learn from our mistakes. We also learn what is truly important to business users and constantly improve the quality and value of our work. Therefore, we're better off being positive about post-development work because in the absence of all this feedback, it is hard to master QlikView.
In addition to a positive mindset, we must possess the basic ability to debug problems. In his book, Debug It!: Find, Repair, and Prevent Bugs in Your Code (Pragmatic Programmers), Paul Butcher proposes the following iterative steps to debug any code:
- Reproduce
- Diagnose
- Fix
- Reflect
These steps also apply to us when we troubleshoot issues in QlikView. Let's take a look at how each applies to QlikView in the following sections.
The first step to debugging any issue is to reproduce it. This allows us to diagnose the anomaly more easily and then confirm that it has been fixed. If we cannot reproduce the issue, then our only recourse is to run a general review of all the components involved and see whether anything stands out as a possible cause. If we don't discover any potential problem, then we could also decide to enable any logging that could help us learn more about the anomaly if it occurs again.
If we can reproduce the issue on our own computer or directly on the server, then it is probable that the issue originates from the QlikView Server, the QlikView document, or the data. Otherwise, if we are only able to recreate the anomaly on the user's own computer, then the problem is usually caused by the network or something in the user's own computer.
For example, QlikView will occasionally not update values that have been cached by the user's web browser. Even though the business user is looking at the same QlikView document with the same selections as those on other computers, they will see different numbers. In this case, we can fix this issue by clearing the user's web browser cache.
Once we reproduce the anomaly, we begin to explore its cause by dividing the problem into smaller parts and independently testing each one. In general, a QlikView document can be broken down into the following parts:
- Script
- Data model
- Expression
- Variable
- Action
- Macro
- Object
In addition to the parts that compose a QlikView document, we also explore the following elements that directly affect it:
- Data
- QlikView Server components
- User's actions
Each of these parts can be recursively divided into smaller and smaller parts. For example, we start by testing an expression and then isolate the problem to its set analysis. We then break this set analysis down into smaller parts and experiment with each set modifier until we find the one that causes the issue.
Also, we often go between various elements in search of the issue's root cause. For example, if we've isolated the issue with an expression to one of its set modifiers but we don't find anything wrong with it, then we look at the set modifier field in the data model. After reviewing the data model, we may need to review the script and, eventually, the source data to find the root cause.
If we know how to fix an issue's root cause, then we can solve the problem right away. Otherwise, we experiment with possible solutions that we find using the resources that we have available or through our own invention.
We must be careful and take into account that fixing one issue may cause another to appear. Therefore, when we solve our initial problem, we should quickly test anything that may be affected by this fix. We should also define a short list of key tests that we run regardless of whether or not we think that they were affected by the fix. These tests confirm the accuracy and functionality of the most important measurements and charts, along with confirming that the application can successfully reload data.
Along with documenting the issue's cause and solution, we reflect on whether the same error could exist in other parts of the application. We also consider whether the same issue may affect other existing QlikView applications or even ones currently being developed. If it does, we analyze if and when to fix them.
We also contemplate on how we can reduce the probability that the same issue will recur. If the mistake is ours, then we should learn from it as soon as we fix it. The issue could also have been caused by some misunderstanding or miscommunication between ourselves and another party. In this case, we work together to find the solution to this issue and continue to work closely to avoid similar ones in the future. In more complex environments, we may also decide to implement tools or processes that help us quickly detect or even prevent future issues.
There are a number of resources that are available to help us during the whole troubleshooting process, especially when we cannot diagnose or fix the issue. We explore the most popular resources in the next section.
QlikView Help is filled with examples of both chart and script functions as well as detailed explanations of almost every QlikView property option. This is often the first resource to go to when we have a question about how QlikView works. The sections about set analysis and incremental loads using QVDs are exceptionally well explained.
Every QlikView application is unique and we should not just depend on a general QlikView knowledge base to fix our problems. Therefore, we need an efficient way to explore development-related documentation along with past issues and their solutions.
The software that we choose for this job depends on our business's culture. One option is to use a note-taking app, such as Microsoft OneNote (https://www.onenote.com/) or Evernote (https://evernote.com/) and have the team share a notebook. We can also use a more minimalist notepad approach, such as GitHub Gist (https://gist.github.com/). We may also use a wiki, such as Atlassian Confluence (https://www.atlassian.com/software/confluence), or a social platform, such as Jive (https://www.jivesoftware.com/), which is the same tool that the Qlik Community uses.
Qlik Community (https://community.qlik.com/) is one of Qlik's greatest assets. Developers from various partners, customers, and even Qlik are readily available to help anyone who has a question about QlikView or Qlik Sense. It is also a great repository filled with QlikView tools, templates, and how-to documentation. Let's keep in mind the following tips when we use Qlik Community:
- Search for a solution before asking a question. We rarely ask something that has never been asked before. Our exact data, script, or expression will be different. However, if we diagnose our issue well enough, then we should be able to find a solution to the same problem regardless of the exact example used in the Qlik Community discussion.
- If we don't find an existing solution, then we create a new discussion with a brief explanation of our issue along with a QlikView application that demonstrates the problem. If we can't upload an application, then we should upload one or more of the following artifacts:
- A screenshot of the issue
- The current script
- The current expression code
- Sample data
- Our expected results
An example application or any of these artifacts is far easier to understand than a thousand-word explanation.
- If somebody helps us, then we should mark their answer as either helpful or correct so that they earn points for their contribution. Qlik Community runs on gamification and earning points is like making money. Let's help keep it this way and spend the extra minute that it takes to "pay" those who help us.
- We must avoid the expectation that somebody else will do our work for us. Some so-called QlikView developers create discussions to find people who will develop a report that they themselves are paid to develop. This is an incorrect use of Qlik Community.
- We can't always expect to find answers to our questions in Qlik Community, especially if the issue is related to QlikView Server. We should escalate such issues with Qlik Support.
If QlikView isn't working as documented in QlikView Help or the issue is related to QlikView Server, then Qlik Support is the best resource to use. Let's keep in mind the following tips when we use Qlik Support:
- Let's not overinflate an issue's priority. If the issue concerns something cosmetic, such as a chart's color, then do not classify it as urgent. Nothing is more annoying or starts a support case on the wrong foot as an overstated priority.
- We can expect the support team to ask us for all sorts of logs, files, and screenshots to help them troubleshoot the issue. Some of the things that they ask us to do or send will appear to be superfluous. However, keep in mind that they are tasked with trying to understand and debug hundreds of issues on remote computers. As this is not any easy job, they do tend to ask for as much information as possible.
- Let's not take advantage of the distance to act overly rude or aggressive. Similar to road rage, technical support rage can be counter-productive. We should promptly and politely answer their inquiries and remain calm.