Break apart Qlikview File

[#1]

I attend Qdays in Chicago and there was a session that looked at what is new in version 10. There was one part that talked about the ability to break apart your QVW file into muliple files so you would have a load script file and a user interface file and so on. I downloaded version 10 but I can't find a way to do it. Any thoughts?

[Qlik_Trigg · Accepted solution]

Note that in version 10 we have introduced the concept of 'project definition files' - component files of the elements within a QVW. To enable the creation of these and the use of them follow the steps below. Note that in version 10 this is totally manual. There are no commands in the desktop to perform any of this. But if you are interested in local source control for your QVW definitions (without the core data and at the individual chart object/code/script level), you may find this interesting.

Setup

1. Create your QVW (e.g. test.qvw).

2. In the directory containing your QVW, create a subdirectory named after your QVW + the suffix '-prj'

a. So if I have test.qvw in directory HOME, I will create a subdirectory in HOME called 'test-prj'

3. Save your QVW

4. Check the subdirectory named after your QVW. You will find one file (either XML or text) for each element of your QVW - chart objects, macro code, script, variables, sheets etc etc. Each is a blank, code only representation of the named entity.

5. Try directly editing one of the files and then reopen your QVW. You will see that QlikView has rebuilt the layout/script etc from the definitions in the sub-directory.

Again, there are no commands in QlikView 10 to create this subdirectory or manage versions or check code in or out of any control system. But if you are interested in local source control for your QVW definitions (without the core data and at the individual chart object/code/script level) and managing and performing all operations manually, you may find this interesting. Let us know

[#3]

That was exactly what I was looking for. I think this feature opens up tons of possibilities for automating script generation.

Thanks much!

[#4]

Oops... meant to click reply not suggest as answer and there's apparently no way to undo that.

Meanwhile, I would suggest being VERY careful when using -prj folders. We have had the following problems and it led to much head-scratching before realizing the -prj folder was the culprit:

* Sheet sequencing was being reverted to the version in the -prj folder even after redoing promote / demote and saving the qvw.

* Copying a different version of the qvw into the folder above a -prj folder can cause very strange results. It appears QlikView attempts to "merge" the qvw with the -prj content???

A little too "buggy" / unpredictable for my taste!

[Qlik_Trigg]

Thanks for the feedback Sue. Definitely first pass. But keen to learn more about how & what you want to use this, and dovetail into our plans to expand its capabilities. Have you logged either of these as bugs?

[#6]

I haven't John. I'm not sure either is necessarily a bug. More testing might be needed to prove whether it really meets the threshold of being a "bug" or whether a development team might really want it to work that way under certain circumstances.

It may be a "sequence of events" / "don't do this" sort of issue...

At the least, I would prefer the system gave you some sort of warning or option if it finds differences between the qvw you are opening and its project file components. I would think as a developer, there may be times you would want it to use the project files and other times you would say NO, I want to keep the version in the qvw.

Make sense?

[Anonymous]

So I finally got around to trying this out today. Very interesting. But has anyone found any practical use in having all these "project" files?

[#8]

We haven't upgraded to Qlikview 10 yet but what I plan on doing is writting a routine that can copy a .qvw and modify the script to a different table. We have thousands of tables in our environment and maintaining qlikview scripts for all of these tables is not practical. This would allow you to

1) have a template .qvw

2) copy the template

3) modify the script to point to a different table

So when something changes or you learn something you want to apply to all your scirpts you could simply modify your routine in one place and then generate all the scripts.

Note: I plan on using SAS but any scripting language would work to accomplish this

[#9]

I've tested to merge different versions of qvw files with this. It can be done, but currently it is a bit too much work. There are some things that complicates matters:

• You don't want to store any data in the version handling system
• The saving of the changed parts in the prj directory isn't stable if files are present
• The file isn't broken apart if you choose Save As on a purged qvw file.
• I didn't find a way to reassmble without having the qvw-file.

If you work around these obstacles it is quite straigt forward. Here is how I did. Lets say the originalfile was file.qvw

• I used git for version handling.
• A added a rule for git to ignore all qvd-files and all qvw-files except files that ended on "*Src.qvw".
• Manually created a fileSrc-prj directory
• Purged the file.qvw and saved as fileSrc.qvw. Save again to make it break apart.
• Checked in all files in the prj-dir as well as the purged fileSrc.qvw. The other file is automatically ignored by my rule.
• I created a branch in the version handling.
• When breaking apart and resaving a file wth contents already in the prj dir, this isn't stable. I needed to remove all the files from the prj-dir and save to make it work reliably.
• While working on the files in the branches, it is ok to work with the file.qvw, the fileSrc.qvw is only used when preparing a checkin and when rebuilding something from the version handling.

After work and changes done and checked in on both branches I decided to merge.

Merge on text- and xml-files in git is like magic, I just merged the branches, opened the fileSrc.qvw and I had the contents from the branches merged. I saved the fileSrc.qvw as file.qvw and continued my work.

A few changes in QlikView would perhaps make this useful:

• A built in tool for rebuilding the qvw from the contents of a prj-directory alone and not having the qvw-file. With this you could ignore the qvw files altogether in version handling and that would be really nice.
• Reliable saving of contents.

Olof Laurin, Senior Consultant at Tacticus AB, http://www.tacticus.se

[#10]

Thank you to all who contributed to this thread.

To sallen and olof_laurin, my findings have been similiar to yours and it was nice to read your words (eg the "Save As" doesn't work; one must perform a second "Save"). Your comments here have been very helpful.

D.Will.

ATP Engineering.