Skip to main content
Announcements
Live today at 11 AM ET. Get your questions about Qlik Connect answered, or just listen in. SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Configuration file for QV to change the connection string without opening the QV script?

Hi,

I have to deliver my Qvw files to my client and they need to integrate the same with their application, so that time the database connection will be changed ,and they should not open the QV file to change the connection string ,rather some config file or some other way should be there from which the connection should be updated from outside without opening the script.

is this possible?

Thanks in advance for any help.

Regards,

Mahasweta

9 Replies
Not applicable
Author

yes, This could be possible.

What you have to do is in the connection string, give a variable.

CONNECT TO [Provider=Microsoft.Jet.OLEDB.4.0;User ID=Admin;Data Source=C:\1st Meeting\$(vDatabase). mdb;];

In the command prompt you can call the qlikview file like below

C:\Programs files\Qlikview\qv.exe sample.qvw/ l /vDatabase = MyDB

MyDB is the database name.

Thanks,

Raghu.

Not applicable
Author

Hi,

we are using a configuration file (ini-file, excel-file or xml) to store these values in external files.

If you are intested in that, please let me know, then I'll send you a demo ...

Best regards

Stefan

Not applicable
Author

stefan,

Can you send me that file.

thanks

Raghu.

Not applicable
Author

Another idea for your question:

You can also put the configuration into a text file and defining a variable there:

let vConnectionString='{Your connection string here}';



Then include the content into your load-script with:

$(include=Configuration.txt);
CONNECT TO [$(vConnectionString)];

Best regards Stefan

Not applicable
Author

Hi Stefan,

Really it would be a great help if you cansend me the demo files, where you are using the configuration files.

Thanks & regards,

Mahasweta

Not applicable
Author

Open a notepad and paste this code let vDatabase='DBName'; and save it as for /eg/ configuration.txt.

In the edit script abvoe the connecting string

$(include=Configuration.txt);

CONNECT TO [Provider=Microsoft.Jet.OLEDB.4.0;User ID=Admin;Data Source=C:\1st Meeting\$(vDatabase). mdb;];

Hopefully this works

-Raghu

Not applicable
Author


Stefan WALTHER wrote:
we are using a configuration file (ini-file, excel-file or xml) to store these values in external files.
If you are intested in that, please let me know, then I'll send you a demo ... <div></div>


Yes Stefan! I am looking for the same. Will thankful to you if you can send me that file.

Not applicable
Author

Hello,

I have the same kind of requirements. I have an excel file, which has file path, table name, column names and aliases stored. Now based on these paths and aliases and columns, i want the load script to load the data. How can i do this?

Arif

Not applicable
Author

Maybe this will help. I setup an XML file with all of the relevant connection strings that I need. I have a copy of that XML file on each of my servers (DEV, UAT, PRD) where the connection name is reused for each data source but the connection string points to the environment equivalent. Now my QVW points to DEV data sources when in DEV and PRD data sources when in PRD without having to change the code.

//load connection string from XML file

LOAD

    TargetDB,

    Connection

FROM C:\Configurations\DataSourceConnections(XmlSimple, Table is [Configurations])

WHERE TargetDB = 'DataWarehouse';

let ConnectionString1 = PEEK('Connection');

OLEDB CONNECT64 to '$(ConnectionString1)';

SQL Select from YourDataWarehouseTable;

//Repeat above for each additional data connection required replaceing ConnectionString1 with ConnectionString2 or some more meaningful name.

Give your client the QVW and the XML file. Walk them through how to use the XML file across all their environments (clearly they would have to make the changes themselves) so that they can manage their servers accordingly.

Ha! It appears I'm 2 years too late in responding to this. Oh well, maybe it will help somebody with a similar problem.

Message was edited by: Dave Hewlett