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

odbc connection string question

Hi,

Does anyone know if the encrypted UserID and Password have a time component or perhaps some unique Qlikview app ID embedded?  I setup a brand new SQL Server and created a user account which will be used for all Qlikview apps.  I noticed the UserID and Password are all different for each of the apps in the ODBC connection string.  Even for the same app, the UserID and Password maybe different when I create it. I would have thought the ODBC connecting string to remain constant as there is only one database account and password to use.  

Anyone can share some knowledge on this?

Thanks much

26 Replies
Anonymous
Not applicable
Author

Is there anyone out there who can provide some feedbacks or comments on this? 

Thanks

maxgro
MVP
MVP

I can share my experience.

I sometimes used an external include with the connection and I send the include to other developers. The connection works for them.

In a connection with scrambled password it's possible to change some parameters (example the initial catalogue for a sql server database) without the need to recreate the string.

I never got an expired connection message from a qlik connection.

PradeepReddy
Specialist II
Specialist II

create one connection string and use the same in all applications.

For easy maintenance store the connection string in .QVS file and include the same file in all applications.

Anonymous
Not applicable
Author

OK.  I just did a couple of tests.  I have an ODBC named "ODBC_SQL" on my machine which points to my

SQL Server database.  This odbc has been configured to point to say "MyDatabase" in SQL Server.  Then

I created two tests QVW files and they both point to ODBC_SQL.  Here are the actual connect string produced

by QV::

//Test_ODBC_1.qvw

ODBC CONNECT TO ODBC_SQL (XUserId is ALYIeYZOVbcKGZNJ, XPassword is XXGaVYJOWLZKXZRGRLYcGSBOcC);

//Test_ODBC_2.qvw

ODBC CONNECT TO ODBC_SQL (XUserId is BUBGcYZOVbcKGZBe, XPassword is FTbcTYJOWLZKXZRGRLYcGSBOfH);

As you can see, both the encrypted login and password are different even though the SAME credential was used when

connecting to ODBC_SQL.  Obviously they both worked.  So I swapped the connect string in both QVW files and they still worked.  What confused me was, hence the reason I posted the question originally, why the encryted strings are diffferent?  I guess if I had 10 QVW files, I could pick any of these connect strings to use, right?

If you can show me how to use an external include file or use QVS to store the connection, i would appreciate it. Otherwise I can do some research.  My background is database administration and development.  I started working with QV recently.

Thanks

Anonymous
Not applicable
Author

OK.  I found this link

https://community.qlikview.com/thread/143983

and created a QVS file with my connect string in it - that's it.  I opened my QVW file and went the script editor

and did Insert - Include Statement.  Ran the QVW and got this error:

SQL##f - SqlState: IM002, ErrorCode: 0, ErrorMsg: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified

ODBC CONNECT TO ODBC_SQL (XUserId is ALYIeYZOVbcKGZNJ, XPassword is XXGaVYJOWLZKXZRGRLYcGSBOcC)

maxgro
MVP
MVP

I use include for all my connections and never had problems.

Today I received a conn string from another developer, add the include file and it worked.

Your error seems related to a missing DSN in the ODBS (system DSN). Check ODBC_SQL presence in ODBC

Anonymous
Not applicable
Author

My ODBC_SQL dsn is there.  This is the same one that I used to create those two test QVW files I mentioned earlier.

So it's there.  It works if I don't use QVS.   maxgro, I noticed in your rejply, you mentioned system DSN.  I have it as

user DSN.  Does it matter?  Well I will create one as system dsn and see what happens.

quwok
Creator III
Creator III

That should not matter for your experiment. A User DSN is specific to your user account and a System DSN is available to everybody on the machine.

Not applicable
Author

Are you testing on the server or in development ?

Please check the ODBC DSN created in the host you are trying.