QV Connect String

[Anonymous]

Hello,

I have been given several QV connect strings.  Obviously both the user id and pw are hashed.

Is there anyway to reverse engineer this so I can see the values in clear text?  My guess is NO.

But wanted to ask just in case it's possible.  I need to know what these credentials are so

the ODBC's can be re-created on the QV server.

Thanks

[felipedl]

Hi Sydney,

What do you need to actually do with the ODBC connection?

Simply connecting in QlikView? If so, just copy the string and it will connect.

If you need to create a ODBC Data Source (as in the picture), it will not be possible and you'll need to contact whoever handles the database.

Felipe.

[Anonymous]

Hi Felip,

Yes, I need re-create the ODBC's in the Windows ODBC Applet.   I handle the database but I was given

the QV connect command which is not helpful.  That's why I was asking to see if it would be possible to

re-engineer the QV Connect string to reveal the user id & pw.  If one can figure out what that API Qlikview

is using when it connects, then we could do it. 

[felipedl]

HI Sydney,

If you administer the database and server side, just create an ODBC pointing to the database your using and recreate the string connection through the ODBC wizard in QlikView.

I'm assuming View is using a specific user (not personal ID, but a generic user) to connect to the database, you could check it in the database and create another ODBC by that.

The driver cyphers the USER/PW so it would be quite dangerous to have this functionality to reverse the hash somehow.

Probably whoever developed the app may know which user/pw was used.

Felipe.

[Anonymous]

Felip,

Yeah I think I am going to end up creating a brand new db account and update any QV app that was using

the "old" account.   I was trying to make this transparent and make it "hands-free" on the QV side.  But I think I will

force an update the these apps.  The people who created these apps are not here anymore and I don't want to manage "mysterious" accounts either.   Thanks for the response & suggestions.

[felipedl]

Yeah, I would see as the better solution for that, since there's no reference to which user is being used.

My suggestions were quite open and hoped I could help you somehow.

One possible way to see which user is used is to run one application that connects to the database and see the last login made to it to narrow it down to a few users.

Felipe.

[oscar_ortiz]

Sydney,

You can try to copy the registry entry from one machine to another:

1. Start regedit.exe.
2. Go to HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI, and highlight the ODBC.INI key in the left pane.
3. From the Registry menu, select Export Registry File.
4. Select odbc.reg, and save it to a network share.
5. Go to your target machine and browse to the same key in the registry. Right-click ODBC.INI and choose Rename. As a backup, rename ODBC.INI as ODBC.INI.OLD.
6. Highlight ODBC.INI's parent registry key (ODBC).
7. From the Registry menu, select Import Registry File and browse to the network share where you saved odbc.reg. Double-click odbc.reg to import it.
8. Test your applications that use the data sources to verify that the import worked properly.

Remember, you can always roll back by renaming ODBC.INI.OLD to ODBC.INI.

Good Luck

Oscar

[Anonymous]

Hi Oscar,

Thank you for outlining the steps here.  This is definitely good to know and will work under a different circumstance.

In my case, I was given only the QV hashed connection string.   There's no way I create a Windows ODBC with

only this information.  The scenario you are giving is good when you need to reproduce the source odbc (source machine) to a target machine.