QlikView + Qlik Sense Blog von Heldendaten

Arbeitet man mit großen QlikView Applikationen, kann das Öffnen einer .qvw von der Festplatte schon mal etwas dauern. Will man aber nur schnell das Skript nachlesen, oder eine komplizierte Formel (bzw. ein ganzes Objekt) kopieren, ist es oft gar nicht notwendig die .qvw mit gesamten Daten zu öffnen.

Hat man die QlikView Applikation unter den "Zuletzt geöffneten Dateien" auf der Startseite gelistet, kann man mittels Rechtsklick|'Applikation ohne Daten öffnen' wählen.
Hat man die .qvw jedoch nicht in der Startliste, so müßte man kompliziert die Qv.exe mit dem Commandlineparameter /nodata benutzen. Wem das zu kompliziert ist, kann sich einen entsprechenden Shortcut am Desktop anlegen. Einfach den Pfad

                                        "C:\Program Files\QlikView\Qv.exe" /nodata


als Shortcut anlegen. Wenn man nun mittels Drag&Drop die .qvw auf den Shortcut fallen läßt, dann öffnet der QlikView Developer die Applikation ohne Daten. Die Applikation zeigt nun alle Listboxen mit "nicht verfügbar" an, aber das Skript und die Objektdefinitionen sind schnell griffbereit.

Eine kleine Warnung: Speichern Sie bitte die .qvw nur mit großer Vorsicht, nachdem Sie diese mit /nodata geöffnet haben. Leider werden bei diesem Feature nämlich keine Frontend-Variablen mitgeladen. Speichern Sie also die .qvw, dann gehen diese Variablen verloren. Gleiche Problematik hat übrigens auf das "-prj"-Ordner Feature für SVN/Team Foundation Server Integration! Als Workaround hilft nur, alle Variablen bereits im Skript zu definieren!

Rob Wunderlich hat sich in seinem aktuellen Blogpost einer unserer Diskussionen vom MasterSummit for QlikView in Barcelona angenommen.

Falls Sie Rob's Document Analyzer benutzen, um Felder am Ende des Skripts zu droppen, hier nochmals meine Beobachtung.

Attached a small example that shows the issue:

- 01_testDatabase.qvw produces a .qvw with about 350MB on disk
- 02_testDatabaseBinaryDrop400fields.qvw does a BINARY Load and then drops 400 fields --> it's about 18 MB on disk (136 MB in Memory including QV.exe)

So one would expect that 18 MB is the final size of the .qvw!
However when I do an additional RESIDENT-Load after dropping fields, the .qvw gets much smaller:

- 03_testDatabaseBinaryDrop400fields_Resident does a BINARY Load, then drops 400 fields and THEN makes a RESIDENT LOAD on the table, dropping the original table

--> suddenly the .qvvw is only 1.2 MB on disk (26 MB in Memory including qv.exe)!
Download Example

Rob hat dies nun weiter analysiert und bemerkt, dass die  Record pointers nicht freigegeben werden.  Erst mit einem weiteren RESIDENT-Load wird tatsächlich der komplette DISK/MEMORY-Space freigegeben.

• Im Moment ist es besser die nicht benutzen Felder im Skript auszukommentieren, anstatt Sie erst am Ende des Skripts zu droppen!
• Falls dies nicht möglich ist, sollte man nach den Drop Fields Statement die (Fakten)-Tabelle nochmals resident laden.

Vergangene Woche hatte ich die Gelegenheit drei Tage am "Masters Summit for QlikView" in Barcelona teilzunehmen. Neben den QlikCommunity-Größen Rob Wunderlich, Bill Lay, Barry Harmsen und Oleg Troyansky, trafen sich gut 50 QlikView Spezialisten aus der ganzen Welt zu Vorträgen und regem Gedankenaustausch.


Die dreitägige Vortragsreihe hatte einen Schwerpunkt auf die QlikView Developer- und Designerrolle, mit dem Anspruch selbst erfahrenen Entwicklern noch die eine oder andere Neuigkeit beizubringen. Also durchaus schwere Kost, die uns aber durch das wundervolle Wetter in Barcelona versüßt wurde :-)

Die Themen waren:

• Advanced Scripting: Vorstellung der QlikView Components durch Rob Wunderlich himself
• Data Modeling: Barry Harmsen ging mit uns durch die typischen Datenmodell-Patterns für Fortgeschrittene inklusive Concat-Datenmodell, LinkTable, GenericKey und AsOf-Kalender (den ich bisher selbst immer Superkalender nannte) für Lagerbewegungen
• Set Analysis: Oleg Troyansky über Alternate State, Bucketanalyse mit Rank und AGGR sowie Advanced Set Analysis
• Effective Visualizations: Bill Lay's Gedanken über die Grundsätze von Stephen Few
• QlikView Competency Center Best Practice: Diskussion des typischen 3-4 Schichten Modells in QlikView (Aufteilung QVD/Datenmodell/Layout). SVN Integration, sowie einige gute Gedanken zu Regressiontesting mit dem JMeter-Tool des QlikView Scalability Centers. 
• Performance Tuning: Oleg Trojansky mit einer ausgezeichneten Erklärung wie QlikView Daten mittles bit-stuffed Pointers in den Symboltables ablegt.

Einzig der Vortrag über QlikView Server Administration inklusive  EDX-Integration, HTTP-Header Authentication und Ticketing schien mir zu wenig in die Tiefe zu gehen. Aber vielleicht ist das einfach meiner Historie als Expert Service Spezialist zu genau diesen Themen bei der QlikTech geschuldet. Dafür hatte unser Blog höchstpersönlich einen Auftritt beim MasterSummit: Das Development Team Easter Egg sorgte für allgemeine Erheiterung nach den anstrengenden Sessions!

Für all jene, die es zu dem Summit nach Barcelona nicht geschafft haben, und auch unseren hd Business Roundtable vergangenen Freitag bei Resch&Frisch in Wels verpasst haben, findet sich eine kleine aber feine Applikation mit einigen Tipps&Tricks auf unserem Accesspoint (auch zum Download).

Roland Vecera

Seit QlikView 10 ermöglicht das Feature "Comment & Tagging" Metainformationen auf Tabellen- und Feldebene zu hinterlegen. Der Entwickler des Datenmodells (zumeist aus der IT) kann somit zusätzliche Informationen an den QlikView Designer (zumeist Fachanwender) weitergeben.

Folgendes Skript hinterlegt die passenden Kommentare zu den Feldern des Kundenstamms.

Customer:
LOAD Firma,
    `Kunden-Code`,
    Land,
    Ort,
    PLZ,
    Region;
SQL  select
*
FROM Kunden;

Mapping_FieldComments:
Mapping
LOAD * INLINE [
    Field, Comment
    Firma, Company Long Name 
    Kunden-Code, Company Unique ID
    Land, Country Long Name from Customer Dimension
    Ort, City Long Name from Customer Dimension
    PLZ, Zip Code from Customer Dimension
    Region, Region Long Name
];

comment fields using Mapping_FieldComments;

Damit erhält der Benutzer am QlikView Frontend in der Tabellenvorschau und bei "Felder auswählen" die Feldbeschreibungen als Tooltip:


Bisher hatte ich verstanden, dass diese Kommentar-Information in der .qvw hinterlegt ist. Eleganter wäre es natürlich, wenn die Kommentare in der .qvd abgespeichert wären. Greift eine .qvw auf die Daten einer .qvd zu, so sollten auch die Kommentare in der Applikation zur Verfügung stehen. So hätte man die gleiche Feldbeschreibungen in jeder .qvw die auf diese .qvd aufsetzt!

Kommentar in .qvd gespeichert

Über einen Supportcase entdeckte ich indirekt folgende Information: Öffnet man die .qvd mit einem Texteditor (oder mit einem der netten QVD-Viewer die es mittlerweile gibt. zB EasyQlik QViewer), findet sich im XML-Header der .qvd-Datei doch tatsächlich ein Tag <Comment> das die Kommentarinformation für jedes Feld enthält!


Sehr nett! Die Frage nun: würde meine Idee mit der zentralen Speicherung der Feldbeschreibungen in .qvds auch funktionieren? Folgende 3 Tests habe ich durchgeführt:

1) Lädt man die .qvd UNOPTIMIZED, erscheinen die Kommentare leider nicht in der .qvw:

LOAD Firma, 
     [Kunden-Code], 
     Land, 
     Ort, 
     PLZ, 
     Region
FROM
Customer.qvd
(qvd) where 1=1;  //unoptimized

2) Lädt man die .qvd OPTIMIZED, bekommt man tatsächlich die Kommentare in der .qvw angezeigt.

LOAD Firma, 
     [Kunden-Code], 
     Land, 
     Ort, 
     PLZ, 
     Region
FROM
Customer.qvd
(qvd);  //optimized

3) Der BINARY-Load verhält sich lieder genauso wie der "UNOPTIMIZED"-Load. Die Feldkommentare werden in QV11.20SR3 nicht in die .qvw übernommen. Abhilfe schafft hier, indem man die .qvd als XML-Datei lädt und sich die Kommentare so manuell hinzufügt:

Binary [2_loadqvd_optimized.qvw];
//SET Variables here

Mapping_QvdFieldHeader:
Mapping
LOAD FieldName,
    Comment
FROM Customer.qvd (XmlSimple, Table is [QvdTableHeader/Fields/QvdFieldHeader]);


comment fields using Mapping_QvdFieldHeader;

Somit haben wir momentan ein "JEIN" als Antwort auf  die Frage einer zentralen Speicherung von Feldbeschreibungen in .qvds! Ich bin gespannt ob die Lücke in neuen ServiceReleases geschlossen wird. Für Fall 1) UNOPTIMIZED gibt es zumindest schon eine BugID!


Alle Beispiele zum Nachvollziehen und Ausprobieren finden sich unter: http://www.heldendaten.eu/blog/commentField_StoredInQVD.zip

QlikView Scripte extern zu speichern ist aus vielen Gründen sinnvoll:

• Config Dateien extern halten
• Wiederkehrende Skriptteile nur einmal pflegen (zB KalenderScript, oder Libraries wie QlikView Components
• Datenbank Connections extern halten, um zwischen Entwicklungs- und Produktivumgebung nicht manuell in die .qvw eingreifen zu müssen.

Der Qlikview Befehl für externe Skripte lässt sich im Skripteditor generieren und erzeugt für eine externe Datei "scriptfile.txt" folgenden Include-Befehl:

$(Include=.\scriptfile.txt);

So weit, so gut! Nur was passiert wenn die Datei scriptfile.txt nicht existiert (weil das File versehentlich in einem anderen Verzeichnis liegt, oder man sich vertippt hat)? Der erfahrende Qlikview Entwickler weiß: Es passiert gar nichts! Per Definition ignoriert QlikView das Fehlen des externen Skripts und läuft einfach mit dem restlichen Skript weiter! Im besten Fall bekommt man einen (irreführenden) Folgefehler, weil zb. die im include-File gepflegte Datenbank-Connection nicht geöffnet werden konnte. Die Fehlersuche kann dann aber häufig langwierig sein, da man zumeist nicht als erstes an das nicht-vorhandene Include-File denkt.

Ein ähnliches Verhalten kennt man aus PHP! Dort können externe Skripte mit "include" (entspricht der QlikView-Denke) oder mit "require" (wirft einen Fehler wenn die externe Datei nicht gefunden wurde) eingebunden werden.

Gibt es nun ein "require"-Verhalten in QlikView? Ja, gibt es - aber erstmal gut versteckt! Toni Kautto hat es als Erster in einem QlikCommunity-Forumthread folgende Lösung gepostet:

$(must_include=scriptFile.txt);

Testet man mit einem Script wie im Screenshot unterhalb, so wirft $(must_include) einen Fehler der klar zeigt, daß die Datei "doesNotExist.txt" vom must_include-Befehl nicht gefunden werden konnte!


In QV11.20 SR3 lässt sich der Befehl nun auch in der offiziellen Dokumentation finden. Damit können hoffentlich auch alle Sorgen (wie an anderen Stellen  in der QlikView Blogosphere geäußert) zerstreut werden, dass dieses Feature nicht offiziell supported ist!


Viel Spaß beim Abändern Ihrer existierenden Skripte & einen schönen Sommer!
Ihr heldendaten Team