Skip to main content
Announcements
Join us at Qlik Connect for 3 magical days of learning, networking,and inspiration! REGISTER TODAY and save!
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

It turns out QV wont' let you choose System DSN.  When I un-checked "Show user DSNs", nothing shows up in my

Data Sources even though I just created a system dsn.

system_dsn.jpg

Anonymous
Not applicable
Author

I'm testing this on my development machine.  Will this only work on the server side when you use QVS?

quwok
Creator III
Creator III

The observation is because you have set it up as a User DSN and not as a System DSN. If you deselect the check box, it removes the User DSN from the list. It should show if you set up it up as System DSN in your ODBC manager.

quwok
Creator III
Creator III

The connection string should work as long as you have a DSN to the data source called ODBC_SQL on the machine you are running the script on.

Anonymous
Not applicable
Author

I'm attaching a screenshot of my system dsn data sources.  As you can see, I have "ODB_SQL_SYSTEM".

Yet when I unchecked "Show use DSNs", my system DSN's are not showing up.  I have a total of 4 system

dsn's on my dev box.  What am I missing or doing wrong??

system_dsn_2.jpg

Peter_Cammaert
Partner - Champion III
Partner - Champion III

Back to your original question:different UserID/Password combinations for different CONNECT strings and different apps, all to connect to the same DB.

The UserID and Password parameters in an ODBC connection string can be specified in two ways:

  • in clear text, which means that everyone with access to the script can read these secret values
  • or scrambled (not encrypted), a process that is performed by QlikView in QV and for QV-use only.

The idea seems to be that the scrambling is intended solely to hide these parameters from prying developer eyes. Underneath, and whenever the scirpt engine needs to connect to a DB through ODBC, these values are first unscrambled and then passed on to the ODBC driver. A bad database implementation may even send these values in clear text across the network, but most professional RDBMS do their own message encryption before sending those values to the remote database engine.

And you're right, the scrambling process uses some variable factor to perform the scrambling. This is commonly called a salt. I don't know if this is a time value or not. But that doesn't really matter, does it?

Best,

Peter

quwok
Creator III
Creator III

Are these 32-bit or 64-bit data sources?

Maybe try ticking the "Force 32-Bit" and see if they appear.

Anonymous
Not applicable
Author

FINALLY !!.  Got it to work.  It needs to be a x64 DSN.  It works either a user or system dsn !

Thanks for that tip, Kwok Chong.

Peter_Cammaert
Partner - Champion III
Partner - Champion III

Don't use User DSNs on a server. If you do, you first need to login as the service account that is running the QlikView services. Otherwise, the reload batch job will be unable to "see" the ODBC definitions that you defined for a different user.

Also keep in ming that on a 64-bit machine there are two ODBC definition lists: one 32-bit and one 64-bit. They do not mix!

Best,

Peter

Anonymous
Not applicable
Author

Peter,

I wasn't aware there is a difference in definition between "scrambling" and "encrypting"?  I thought they meant the same

thing but under the hood, the algorithm used maybe different.  End result is you're changing a clear text to a non-clear text.  I always encrypt application credential used in a connect string when storing in a text file and have a process to decrypt it just right before it hits the database server.  So when I saw the UserID and Password QV produced which looks very similar to the algorithm I used, I thought they were "encrypted".  But regardless, I now know it really doesn't matter whether they are the same or not or why they are different each time I create them, I can use it in any QV app that needs that connection.  However QV does it, it has to produce a user id and password that the database server

permits you to connect to.

I would be interested to know a bit more of the diffference between scrambling and encrypting in QV.

Thanks