How does the Developer's machine need to be setup

[paputzback]

So far from what I have read is that the framework is setup on the server. I don't see where the developer does their work and how their local copy of a QVW can access connections through the few variables you set in the main tab that point to locations that do not exist on your PC.

I plan to watch the videos tonight, but I just figured this would be explained in the getting started doc.

[Magnus_Berg]

Hi Philip, as you wrote, the videos are a good start.

You need to put the qvw in a container resided on the local computer, as every container have the same logic the local environment will mimics the server environment. The qvw can there by be moved across environments. Will look how the Getting started Guide could be improved.

Best regards

Magnus

[m2r4miller]

We have QDF set up on our test server \\qlikviewtst and all containers are built only there.

Each developer has only QV installed on the development machine and we keep the QVW, QVDs, etc. in containers on the server.

We open the QVW in our desktop copy of QV directly from the server - here is a picture of the Recent part of the QV Start screen:

We find this setup works perfectly for us - all the scripts run as described in the QDF docs, and the server is backed up nightly as well.

This keeps our development PCs clean, and keeps us very organized to boot.

A further advantage is we (there are 5 QV developers here) can easily see what others are working on, work together on apps, etc.

Hope this helps.

[paputzback]

When you do a reload from the QVW desktop copy, does the QDF init script know to pull its variables from the remote location? I got through 3 or 4 videos this morning and was expecting to see the developer to work from his local machine once the application was setup on the QV server.

I wasn't expecting to see the QDF root folders go into the QV root where the pgo files were. I wish the QV configuration would let you keep those files in a specified directory.

Thanks for the info. I hope to finish the videos today and install the QDF on test tonight.

[m2r4miller · Accepted solution]

Absolutely!

We let the Container Map Editor do its thing in creating the containers for us and everything "just works":

This is a shot of Container Map Editor (which is in the 0.Administration container on the server) open on my desktop:

This is a shot of one of the containers on our test server:

Here is a shot of the script progress dialog after a reload of the 2nd QV app seen in the image in my last post:

[paputzback]

I saw the video of the container map. I will go with what you said, It Just Works. I was expecting the reload to show paths back to the remote location. When you run the reload on your local machine, does it recreate the remote container structure locally?

[m2r4miller]

We store the application-specific QVDs in the 2.QVD folder of the container and the actual QVW in the 1.Application folder.

Nothing for the app is built, stored, or maintained on our local PCs. Doing a reload does not create any folders on our local PC.

In the script of the QVW, we reference the QVD location like this (I don't use '*' in the script, just being lazy here 😞

LOAD *

FROM
[$(vG.QVDPath)RECLM627.qvd]
(qvd);

The script tabs are set up as follows (per QDF documentation):

The INIT tab is always first, per QDF docs.

The Notes tab is just that - a place for the developer to put any notes he/she may want.

The Main tab is generally just the SET statements that start any script in a new QVW. We may load data on this tab, but not generally.

Tabs between Main and Master Calendar are where the QVDs and other data are loaded and it is not unusual for us to have many such tabs - I like to put separate file loads on separate tabs, especially if I'm doing a lot of scripting during the load.

We put all tables being loaded via MAPPING LOAD statements on a separate tab (usually the Mapping Load tab is the first tab after Main).

Finally, per QDF docs, the Master Calendar tab is last (or at least after the data is loaded that you are building the calendar from).

When we do a reload, the INIT scripts set all the variables for us, and everything is relative to the server, even though we are running the QV application locally on our PC:

[paputzback]

That was some great detail. Thank You. I like the "Tips, Tricks and Best Practices". I never thought to put a "Notes" tab in the document.