I'm having a thought on the generall process of building QV documents, but I don't want to distribute any false assumptions to new users.
Maybe one of the mods could look over this and tell me whether this is so or not - if it is, I'll make it into a document:
just a thought on the general how-to of building QV documents:
When building documents which will be used by other people, it seems generally advisable, rather than use formulas on the frontend of the document, to include the same formulas into the script in the background so that the users do not have to worry about breaking anything - by using the SECTION ACCESS method in a script, you can control whether the end_users can even see the script.
This method also has one other advantage: When you add a statusbox to your document, it is essential that the fields on which selections are made (usually listboxes) are already the correct (calculated, formatted) values - it is not possible to use formulas in a statusbox.
=> Scenario: In my document, the original field to make selections on is a date-time stamp which is different for just about every record, but in the listbox I only wanted to display a day/ week/ month. When using formulas inside the listboxes, the original date-time-stamp field was used by the listbox and then, instead of listing all the values selected, the box said "1.300 of 20.000" or the like - not helpful. So I went to rather doing the calculations in the background (in the script) and using the finalized calculated fields in my listboxes and the statusbox correctly displayed the value of one of these fields that was selected.
HTH
Best regards,
DataNibbler
P.S.: I think that this on the other hand does have a negative influence on script reloading time, doesn't it? In that case, how to weigh one against the other here?
I just read up on a trick to greatly reduce the RAM footprint of a Qlikview document: Leaving out fields with "high cardinality" (a lot of potential different values, like date-time-stamps) can boost performance because fields with "low cardinality" (only few potential different values) can be better compressed by QlikView which, because of the In-memory-technology, is quite important - all data is stored in compressed form in RAM by Qlikview.
one more trick that just came to my mind: Recalculation of all diagrams every time you change something can be cumbersome - especially if, like here, it takes a while and if the data becomes too much, all will hang - it is simple to tell QlikView not to recalculate a diagram at all - simply add a condition (one that is never true, like 1=2) on the "General" tab of the properties dialog.
