Deployment and Data Architecture Operations: QVD Layers, Reload Scheduling, Publishing, Environments
Layers, tasks and the order of reloads
A mature deployment separates extract, transform and presentation layers. Extract QVDs mirror source tables with minimal change; transform QVDs hold cleansed, conformed, reusable data; the app layer consumes transform QVDs and holds almost no script logic. This means one failing source is reloaded once, apps stay small, and the presentation layer is cheap to rebuild.
Reloads are scheduled in the Qlik Management Console as tasks with triggers: scheduled, event-based, or chained to another task. Dependencies matter. An app reading a QVD must run after the task that writes it, otherwise it silently reloads stale data. Use task chains for ordering and alerting, and check the execution log rather than assuming success. Where the source allows it, incremental or partial reloads shorten reload windows - at the cost of needing a dependable key and explicit deletion handling.
Publishing is a governance act: an app is published to a stream, and edits go through a managed copy that must be republished. Republishing replaces the published version, so validate in a test app first. Keep separate development, test and production streams, restrict who may publish, and manage data connections centrally because credentials live there. Environment portability matters too - hard-coded file paths and machine-specific ODBC names break when an app is promoted.
Rule of thumb: sketch the task dependency graph before writing script logic; every QVD should have exactly one producing task and at least one consuming app.
Worked example: Task A extracts ERP QVDs at 01:00, Task B builds the transform QVDs chained to A, and the sales app is chained to B - no overlapping windows and no stale data.