Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

Announcements
Write Table now available in Qlik Cloud Analytics: Read Blog
cancel
Showing results for 
Search instead for 
Did you mean: 
justindallasverizon
Contributor III
Contributor III

Disable Connection w/out Deletion

Hello Folks,

I would like to disable some database connections without deleting them.  I would also like to prevent sa_repository from invoking them too so users can't reload them through the QMC Tasks UI.

I know I can make my custom rule have a clause like "And 1=0", but I don't think that would stop sa_repository from getting a hold of it.

 

Any help is greatly appreciated.

Labels (2)
1 Solution

Accepted Solutions
Levi_Turner
Employee
Employee

You're right that sa_repository will be able to access the data connection (via rule named ServiceAccount).

I am a fan of @Or 's suggestion to rename the _name_ of the data connection. Even for ODBC (or OLEDB) based connections, the invocation in the load script is via the name of the data connection:

Levi_Turner_1-1753361324609.png

Levi_Turner_2-1753361397862.png

Renaming is a great "sc ream test" to see who uses it. Alternatively, you can audit what apps use the data connection (https://github.com/eapowertools-archive/qs-data-connection-analyzer, warning it may take a while to reload, so you may need to adjust the reload task for >1day).

From an access control standpoint, you could filter out user access via auditing what rules would grant access then adjusting them but to your point, for an existing app which has a reload task, the service user would still be able to access the data connection.

 

View solution in original post

3 Replies
Or
MVP
MVP

If you'd like to prevent them from being used to read data entirely, you could just fudge up the connection details, e.g. by adding a 'z' to the start of the connection string. Any attempt to use this connection to pull data will fail. 

justindallasverizon
Contributor III
Contributor III
Author

That was my first thought, but they are ODBC connections, so they live on the server and not in the QMC =(

Levi_Turner
Employee
Employee

You're right that sa_repository will be able to access the data connection (via rule named ServiceAccount).

I am a fan of @Or 's suggestion to rename the _name_ of the data connection. Even for ODBC (or OLEDB) based connections, the invocation in the load script is via the name of the data connection:

Levi_Turner_1-1753361324609.png

Levi_Turner_2-1753361397862.png

Renaming is a great "sc ream test" to see who uses it. Alternatively, you can audit what apps use the data connection (https://github.com/eapowertools-archive/qs-data-connection-analyzer, warning it may take a while to reload, so you may need to adjust the reload task for >1day).

From an access control standpoint, you could filter out user access via auditing what rules would grant access then adjusting them but to your point, for an existing app which has a reload task, the service user would still be able to access the data connection.