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?

[#2]

Hi John, that all makes sense and reloading and saving generates the appropriate files. 

I'm unable, though, to edit one of the files (e.g. LB01.xml) and see the changes reflected in the .qvw - any document properties need enabling in order for this to occur?

[#3]

I've done some initial testing with QlikView 11 on version handling.

It seems as the stability problems of version 10 are gone. But Save As on a purged file still does not break it apart and I've found no way of creating a file from prj-data alone. But these might not be such big issues after all.

If you configure git to ignore all .dat and all .qvw files you can work as usual with commits and merges. The problem arises when you fetch a new repository without and qvw file. But simply copying and renaming an empty qvw file solves this, when you open it, it recreates the original document (always without data).

The conclusion is that it seems as you can use git to version control QlikView 11 files quite easily.

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

[#4]

Hi,

I am trying to overcome the problem of changes in the qvw file being overwritten by the prj folder.  This happens if the qvw has been modified on the client site, then I bring it back into my development environment, which is managed using source control.  I have lost changes a couple of times, because the prj files get "merged" back into the updated qvw.

If I understand your steps correctly, Olof, you suggest maintaining two qvw's (file.qvw and fileSrc.qvw)?

The only way I have got this to work, is to use Export Document Layout from file.qvw, then copy the output (xml files) into the fileSrc-prj folder.  Then you need to open fileSrc.qvw, merging in the updated xml files.  Only then can I check in my pending changes.

For context, I am using integrated source contorl with TFS.

Is there an easier method than I have described above, or has someone created a different thread specifically for this issue?

Regards, Michael

[#5]

Hi Michael,

We are using TFS 2010 and QlikView 10 (not using integrated source control, but the following suggestions may still be beneficial). Earlier we had run into same/similar problematic behavior as you describe, but by following some well defined steps we’ve had fairly good luck working around it (by working with it).

Here is what we do, in the unique scenario where we wish to merge into source-control a copy of the qvw that was modified outside of our formal development environment:

1. In TSF Source Control (we use Source Control Explorer in Visual Studio), perform a “Check Out for Edit” against the qvw file (if you manage it under source-control).
2. In TSF Source Control, perform a “Check Out for Edit” against the –prj folder.
3. IMPORTANT: In the development environment, using Windows Explorer, delete the local contents of the –prj folder.
4. Copy to the qvw’s home folder the new, externally modified qvw file, thereby overwriting the existing, local copy of the file.
5. Open the qvw file using QlikView Desktop.
6. Perform a straight “Save” of the qvw file using QlikView Desktop (even if no changes have been made). This will cause QlikView Desktop to regenerate the xml files in the –prj folder (examine the folder to verify).
7. Optional: Close QlikView Desktop.
8. In TSF Source Control, kick off a “Compare” against the –prj folder; perform a “Delete” against Server Items for which there are no corresponding Local Items; perform an “Add” against Local Items for which there are no corresponding Server Items.
9. In TSF Source Control, perform a “Check In Pending Changes” against the –prj folder.
10. In TSF Source Control, perform a “Check In Pending Changes” against the qvw file (if you manage it under source-control).

I hope this is helpful.

D.Will.
ATP Engineering.

[#6]

Thanks for the reply.

Nobody on our QlikView team are actually using Visual Studio.  This is part of the reason why integrated source control in V11 is so valuable.  Unfortunately, it means that the process you have outlined does not work for us.

[jerrysvensson]

Hi all.

An old thread but I hope someone can help us.

We have a problem with recreating Triggers on fields. When we try to recreate the application all field triggers are removed.

We are running v11 SR2, but I verified it on latest v11.2 SR3.

Are we doing something wrong?

Has anyone got Triggers working with Source control?

Steps:

Created the -prj catalog.

Open the app and saved. Xml files are created.

Deleted app and then created a blank QV app with same name.

Open app and reload.

No triggers are left.

[#8]

Hi

We are using GIT with QV11 but I have an issue and some questions with the PRJ files:

The following scenario:

When I get the latest source code, the PRJ folders files are updated (datetime stamp) with latest schema.

How do I get my qvw solution refreshed with the PRJ schema?? I read on the forum that open and save as with overwrite would do the trick. If so, then I face the issue that GIT "sees" a change to that folder because I had to save it although no real changes have been made.

Am I doing something wrong in the process of getting the latest solution vs GIT?

Thx in advance

Paul.

[jerrysvensson]

To get your changes you have to open and save your app.

Publisher (qvb.exe) doesn't do that unfortunately.

We accomplish this by: qv.exe /r app.qvw and then the Publisher will reload and publish.

[#10]

Yes, but my point is, when I save them, GIT sees this as a change although nothing has changed.

[jerrysvensson]

Yes. Ask Qlik about that. 🙂