Discussion Board for collaboration related to QlikView App Development.
Next week I'll be working on massive dataset (atleast for my experience with QV) which is around 35 million records with 12 columns and I wanted to know the best practices to speed up the document? Please can someone share good practices for efficient development.
I know this is a vague question but this is really important for me...
Many thanks in advance.
my self Mallikarjuna
i want one help please send interview questions and answers following below
If qlikview couldn’t find the file in the destination folder, it will throw up error. How to disable it? (Errormode=0
Hello Miguel Angel Baeyens,
How are you? Your reply above was very informative. What peeked my interest is on point number nine;
9.- Avoid RESIDENT loads. If needed, load twice from a QVD.
Can you elaborate more?
Thank you for your kind attention.
Khairul Anuar Azuddin
About point 4:
Using autonumber is better for reloading faster or for re-calculation after selections? Or both?
I have a complex key that concatenates 3 numeric fields with "&'|'&" and I don't care much about reload because it's done late at night, but I need to make my application faster for user selections.
The best practice is to use this syntax: autonumber(keyfield,'keynickname'), right?
Don't let this topic die!
Wow! this is still most viewed answer after 7 years.
Pedro - Answer is both. You want to use AutoNumber not just for reload time but also for frontend calculation. The compact keys are super efficient because they fit nicely without splitting. And compact keys are efficient for fast traversal. Faster Traversal is important when you have the data model with multiple tables.
So, I highly recommend using AutoNumber instead of long concatenated keys. You can always store in the QVD files for debugging. And you can bring them into the app when you need to debug. I had seen some developers create the autonumbers and keep the original long concatenated keys, which is useless, to be honest!
All the best!
Thanks! I'll implement that, but I'll have to keep the long complex keys because some users want that in tables for auditing. I know it doesn't make sense, but...