When asked how to aggregate data in Qlik products in the quickest way, the answer is “it depends”. While the key factor is the uniqueness/ cardinality of the aggregating dimensions, there are other elements at play.
In general, though, the fastest way to aggregate in the data load script (after loading the data into memory) is:
When aggregating by a low cardinality dimension in a small data set, resident load and run a group by immediately (this is also the fewest lines of script)
When aggregating by a higher cardinality dimension, or on one that requires a lot of sorting prior to aggregation, resident load and sort the table by the high cardinality dimension as the first step. Then resident load this table and run your group by as a second step.
The short version: use approach 2 as the default, unless your data is very simple.
Today, QSE SaaS doesn’t do task chaining. Instead you have two options:
Use a scheduled reload task for every app, and try to make sure the start time for task 2 will always be later than task 1
Use Qlik SaaS REST APIs to trigger the reload
This post covers a simple approach (i.e. Qlik script only) for triggering reloads of downstream apps on completion of an app reload in a way that doesn’t require much maintenance or any external systems or integrations.
When you’re troubleshooting or diving into logs, it’s useful to have a mapping of object types. The name of an object is defined by the developer of that object, so there tends to be little convention – other some basic syntax rules and that Qlik Sense only allows one instance of the name per site.
Knowing what each type means is useful when inventorying a site for upgrade or migration.
Following a system restart, an overnight shutdown or a system update, some Windows services don’t always come up successfully. This script runs via Windows Task Scheduler and accepts one or more service names.
If the service isn’t running, it attempts to start it – and produces a log file to capture the incident.
The main benefits of this script are that it requires a single row addition per log, with no manual increment of the version number, and the version control information can be surfaced by the engine either to the UI or via the APIs.