Discussion Board for collaboration on QlikView Management.
I'm working with a solution where we use SQL server and SSIS as our data warehouse and ETL tool. The data warehouse generates most of the data for our QlikView reports.
Regarding our SSIS packeges we use the Tortoisesvn (http://tortoisesvn.tigris.org/) software for Revision control / version control / source control software, etc.
I'm wondering if anyone knows about software we can use for Revision control / version control / source control software for our ClikView soulution?
And tips and advices for stuff we have to think about when implenting such a solution...?
Our current sollution is not good enough where we store al qvw/qvd files on one server and with noe check-in control or "rules" for deployment and change handeling...
Hope any one can help - all advice is appreciated especially experiences anyone might have considering this issue...
It does, however you need at least QV 11.2 SR5, from where triggers are defined in the document level rather than field level.
I have also found that I do not have the time to compile a nice document for this, so I will just post how to do it right here.
In short, we do like this:
- All developers work against their own local file repository, ie. D:\qv
- Developers check in to source control
- The build server downloads latest source for nightly builds
- QV.exe /rp opens all apps that have a corresponding -prj folder.
For /rp to work, we have a special script part in the beginning of each app script that does something like:
if IsPartialReload (bla bla bla create inline table, drop inline table, exit script)
- Now we have an updated .qvw from the latest source
- The publisher does a normal reload on all apps, both ETL apps and frontend apps
- Another custom web page shows a dashboard of logs from all reloads as well as app versions to get a view of
the nightly build result.
Interesting that the field triggers problem has been taken care of in SR5. Why do you do the partial reload trick? Just to save time not having to do a full reload of all qvws?
Wrote a little about our struggles with Qlikview and Mercurial, another DVCS here, would be interesting to hear if you share any of those experiences other than when it comes to variables and field triggers: Qlikview and version control, part 3 - Sigma Blogg
We do the partial reload in order to refresh the QVW with changes in the -prj folder because, IMO, binary files have no place in a version control system. And often they can grow *very* big.
Also, the Publisher is unaware of the -prj folder and thus would reload the old version.
There are some API-calls we could use in both VB-script and PowerShell, but they bugged on us and we ended up using command line after all.
The plan was to do like below, without having to call QV.exe from the command line:
- Open app
- Save app
- Close app
Had I had seen your post on Sigma prior to writing my reply, it would have looked somewhat different 😃
If you have problems running version control and QlikView you can maybe find help in QVScriptor that handle .prj files a smarter way alongside with .qvw and automatically.
It handles front end variable and losing triggers and do publication to QVServers also
have a look here
Just to tell you that we have implemented qvw merge in Version Manager and it works well
Contact me at email@example.com
the technique with /rp reload to build .qvw files works very well. I made a video about the advantages here: https://youtu.be/wyazFgUotAQ
I would recommend setting it up as a continuous deployment scheme however, rebuilding qvw directly after commit (and push) and after that automatic deploy to QV Publisher then reload it through QMS api edx trigger. No need for nightly builds 🙂