Evolution of a QVD Extracting Application (the .QVW Juicer)
When I shared the original version of this, it was about the end of my first year of QlikView exploration. You can check out the original version here
This application has always done everything I asked it to, but looking at it now with the advantage of a few additional years of experience, a more discerning eye makes it clear what can be adjusted, what can be kept, and what can get tossed overboard. Ballast just keeps going over the starboard bow (don't hold me to that, I'm not hyper-nautical) .
The functionality of the app remains the same, but the approach I took as a first year Qliker vs. today is radically different. During earliest approaches at auto-scripting I had this notion that scripts would render in the Progress Window during script reload, and they would be cut&paste from there. This lead to odd programmatic sequences trying to preserve whitespaces, render semicolons, and single quotes without having the script progress window derail.
These kind of convolutions no longer appear necessary, and rows of code are stripped out, the application hammered and honed down. Extra variables removed, odd iteration sequences reconfigured... the app does the same thing as before but leaner, more efficient, more consistent.
Whereas before it was a hammer with a mounted cupholder, now it is just a hammer. And when I return again years from now, there probably won't be any programming involved at all, I will just mentally think about activating the 'telekenisis' feature and the nail will drive itself.
So for a variety of reasons (not the least of which was to complete the QlikCommunity mission which awards 100pts for posting your first document) , I decided to revise and post again.
Which leads me to present to you...
the New & Improved QVD Extractor!!
(**pause here to wait for applause to die down)
Ladies & Gentlemen... Have you ever had a situation where you found yourself looking at a "spaghetti" data model and wondered how you're going to make sense of it all?
Whether it's some form of technical hazing, or there just wasn't time to document a long and voluminous list of components, looking at diagrams like this one can make as much sense as staring into a bowl of M&M's.
If you're going to start working on an unfamiliar application with a complicated data model, you've got to identify the most important components of the data relationships, but they're buried beneath a horde of cloned and user-interface related tables. How do we separate the wheat from the chaff?
Binary load is an all-or-none deal, wouldn't it be easier at times if you could just pick and choose which tables from the data model you want to work with?
That's where this QVD_Extractor has helped me in the past.
This application will binary load from a source .QVW and export every table it detects in the data model and store it to QVD. It follows up on that step by creating a LOAD script that corresponds to every QVD it created during the reload.
Now you have a series of QVD and a script which will quickly allow you to pick and choose which subset of tables from the overall data model you wish to begin working with, and if you want to use them all, it should recreate the data faithfully in the same sense that a Binary load does.(see screenshot)
Lets say you're in the scenario where the original .QVW application was something that only reloads on the client's server (which you might not have access to) and the orginal script took 15 minutes end-to-end to regenerate. You now have the capability to empty out the original script, replace it with the script generated by the QVD_Extractor, and have a reloadable copy of the user-interface, that doesn't require a database or network connection.
If the application you extraced QVDs from was a functional copy, then the series of QVDs extracted is EXACTLY the data model that application requires to reload.
From that point forward you can begin reverse engineering the mechanics of the data-to-ui interactions or data-modelling as desired, no longer restricted by the inability to tap into the scripting logic phase of application design.