Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
Anonymous
Not applicable

Development/Test vs. Production Data connections

I am curious if anyone came up with a better way to handle data connections to a development (or test) database vs. production database, using Qlik Sense Enterprise environment.

We do this in QV easily by including connection strings, using relative paths and mirrored folder structure for DEV vs. PROD projects but I cannot come up with something like that for Sense since it is so different.

The only idea I have in mind is to set up two data connections with different names (e.g. MyDatabaseDEV and MyDatabasePROD) and somehow detect name of Qlik Sense app or UID and change names of the connections in the load script. But I hope there is a better way that someone found.

Thanks!

6 Replies
Anonymous
Not applicable
Author

so I just tested the technique below and it works but I am not really happy since developers would have to remember to change the vEnv variable manually before they publish their app for production use and also circumvent LOAD statements.

1) create two separate data connections using the same name plus DEV or PROD keyword:

e.g. MyDatabaseDEV and MyDatabasePROD or MyDataFolderDEV and MyDataFolderPROD

2) In load script, add new variable

SET vEnv = PROD;//set DEV or PROD to switch between development and production data connections

3) finally, add your data load statements using either DEV or PROD connection and modify LOAD statements.

FROM:

LOAD *

FROM [lib://MyDatabaseDEV/10_Data/TestProject/TestDataFile.txt]

AFTER:

LOAD *

FROM [lib://MyDatabase$(vEnv)/10_Data/TestProject/TestDataFile.txt]

4) now you can decide if you want to load DEV or PROD data by changing variable vEnv in your script.

But I really really hope there is a better way or at least one in the works by Qlik.

vadimtsushko
Partner - Creator III
Partner - Creator III

Hi, Boris.

For similiar problems in our projects we use following pattern: We separate creating of Dev/Production mode switch variable into it's own file and then `must_include` that file into our scripts.

With such approach we separate source files into two parts:

1. File that is logically related to site/environment (Dev/Production) and typically not changed after initial creation of that project/site pair. Crucially that file is not checked into CVS system. In your example such file would consist of one line:

SET vEnv = PROD;

2. All other source files that are logically related to project, transfered between sites and constantly change in project lifetime. These files are under the CVS sytem governance

Olip
Creator
Creator

Hey Vadim,

Could you please elaborate further with an example?

Thanks,

Alip

- Eager to learn n grow,

Olip
ergustafsson
Partner - Specialist
Partner - Specialist

If you a Library within every environment (with identical library names), you can include a must_include references to a text file pointing out the environment. E.g. SET vG_Environment = 'dev';

You can also make it automatic within each environment: Multi-tier deployment in a single environment - let apps automatically know which datasources to use...

rittermd
Master
Master

I always make sure that the Data Connections names are the same in both environments.

When you first create a Data Connection it includes the user name as part of the name.  So I go into the QMC and remove the user name and apply.

So in DEV my Data Connection name is say QVDS.  It has the same name in Prod.  They can both be pointing to the same or different actual data.  For example if this is a folder.  It could be in a different location on each server.  But that will not matter to the app itself.

But the beauty of this is that when I publish the app I don't have to change anything and I don't have to deal with variables. 

This seems to work very well for us.

ogster1974
Partner - Master II
Partner - Master II

QDF Qlik Sense Getting Started Guide

I've come across this and I'm going to explore it for my environment.  perhaps useful for you.

Regards

Andy