Analyzing Your QVPR

The Qlikview Management Console (QMC) is used to define Reload and Distribution tasks for your Qlikview documents. These definitions are stored in a set of XML files — the Qikview Repository (QVPR) — located in C:ProgramDataQlikTechManagementServiceQVPR on your server.

The QMC provides a good overview of scheduled tasks, but a better analysis is sometimes need to answer questions like:

  • What documents are being scheduled on a Monthly schedule? Weekly?
  • What documents are using Dynamic Distribution (reduction) and what field controls the distribution?
  • Which administrator modified this task and when?
  • What documents are being distributed to group Accounting?
  • How many documents are being distributed as PDF?
  • Do I have logical errors in my QVPR?
  • When was my server upgraded?

I’ve produced a “QVPR Analysis” tool that loads the QVPR XML files and makes them available for Qlikview analysis to answer the above questions and more. You can download the QVPR Analysis tool  from the “Tools” menu of QlikviewCookbook.com.

The download link above contains some screenshots from the tool (names are scrambled in the images).

You can load directly from the server QVPR folder or an offline local copy obtained from the server. The offline capability makes the tool especially useful for remote consultants who can analyze a customer’s configuration without having QMC access.

This is the same tool provided to Masters Summit for Qlikview attendees last year. If you’ve already received a copy, no need to download again. I plan to continue enhancing the tool and will release further updates on QlikviewCookbook.com.

The analysis is pretty much text and tables which has suited my needs just fine. I’ve used the tool several times to solve some tricky customer problems or get someone out of a jam.

If you have Qlikview Publisher, you’ll get detailed information on Distribution tasks. If you don’t have Publisher, you won’t have distribution information but you’ll still get useful information on reload schedules and QVPR structure.

If you build some new analysis or find the tool useful, drop me a comment.

-Rob

Share

10 thoughts on “Analyzing Your QVPR”

  1. Hello, Rob.

    In the About.xml file, from QVPR folder, there is every release we have installed. But it ends in QV 11.2 SR7. We now have the QV 11.2 SR10 version and it doesn’t appear in that file. Do you know why? Thanks.

    1. I noticed this at a customer site the other day, and didn’t understand it. It may be that an entry is only made when the DB requires an update. Maybe there weren’t any DB changes from SR7 to SR10?

      The About on my local machine has an entry for both SR5 and SR10, so I’m not sure. But I’m going to look into it.

      1. Rob, you are correct, the version info will not change if there has been no change to the QVPR XML schema files, and I believe the last change was SR6 from what I have seen, so whatever release you have installed SR6 or later will be what is logged in About, but any subsequent updates will not likely write an entry… I recently confirmed this with R&D.

  2. Hi, Rob

    Kindly thank You for this usefull Document!
    In QVPR Analysis there several ID key fields, among them :
    DocumentTaskId,QvsRecourceId and so on.
    Is there ane fields to definetely indentify (existing file-task name-distribution name) ?

    1. The keys are loaded as they exist in the QVPR. There is not a single key that links a file to a distribution name. However, qvw names are associated with distribution names through the task relationship. Not sure I am understanding your question?

  3. Rob –

    I love your app. I am using it and adding some stuff to it for our needs.

    I have a question about the QVPR files, specifically the SourceDocument.xml file. I would expect the SourceDocuments.xml file to contain a list of all qvw files in in the Source folder (and, possibly, the subfolders). However, that is not exactly what I am seeing.

    I am hoping you understand the purpose of these files. I can’t find anything that answers my question on Google.

    So, we have the following structure of files (numbered for reference below):

    Source Documents
    – AppGUIs (1)
    – Archive (2)
    – QVDBuilders (3)
    – Layer1 (4)
    – Archive (5)
    – Layer2 (6)
    – Archive (7)
    – Layer3 (8)
    – Archive (9)

    When I look at the SourceDocuments (SD) file, I see extra files in one sense and missing files in another. For example, for the Layer1 folder, #4, in the folder there are 125 .qvw files. However, in the SD file there are 178 .qvw files listed for that folder. Now, those extra .qvw files were in the Archive folder (#5). But, I renamed those files to start with ‘Archive – ‘ and the SD file did not update the file names to the new names, so I assume it isn’t looking at the subfolders.

    Another thing to note is that I was trying to get the SD file to refresh yesterday so I created a task against one of the ‘Archive’ files in the folder #2 above. It did refresh the SD file. It added the ‘Archive’ .qvw file to the SD file. I deleted the task, but the ‘Archive’ file will not delete.

    So, from what I can tell, the SD file contains .qvw files that are in the folders listed in the SourceDocumentFolderResource.xml file. It does not list the ones in the subfolders unless there is a task against it. However, it also does not seem to refresh the list removing files that no longer have a task.

    This makes for a list that is not accurate. Do you know how to refresh the SD file to remove old files? Like I said, I created a task and it refreshed the file, but it didn’t remove old files.

    How do I get QlikView to refresh this list? Do you know?

    Thank you.

    Tammy

    1. So the indent didn’t work for my folder structure. I also realize I can add something about that.

      First: the two source folders in the SourceDocumentFolderResource.xml file are the AppGUIs folder and the QVDBuilders folder.

      The Layer 1, Layer 2, and Layer 3 folders are subfolders of the QVDBuilders folder.

      The Archive folders are subfolders of the folders above them.

      Something that is a little different from what I said above is that for the QVDBuilders source folder, the files in the Layer1, Layer2, and Layer3 sufolders are shown in the SD file. There are no files in the QVDBuilders folder.

      So, for the AppGUIs folder, it looks like the system does not look to the subfolders. For the QVDBuilders source folder it looks like it does look to the first level subfolders but not to the second level subfolders.

      I hope this helps and thank you for any help you can give me.

      Tammy

Leave a Reply to Tammy Freeman Cancel reply

Your email address will not be published. Required fields are marked *