global variables with hidden values
-
hi,
i want to make a DTS package to import some flat files to sql server.
i created the package on a test server. i added some global variables (strSQLServerName, strSQLServerDB, strSQLServerLogin, strSQLServerPassword, etc) of type "String".
i want to hide the value for "strSQLServerLogin" (to be not shown in "DTS Package Properties" window)
any suggestion?
10x
-
I don't think that's going to work for you in any way I can come up with. Perhaps another file with the password. Perhaps embedding in an ActiveX task. The problem is that none of those are secure, especially if this is something people need to run without you around.
Can you set up trusted authentication for these users and give them just Insert rights to do whatever they need to do or is that too many permissions for them to have?
Do they have access to Enterprise Manager or can they just use DTSRun.exe?
-
i want something like this:
The DTS is schedule to run at midnight. i don't know how this global variable is set.
the ActiveX script has the following code:
Dim conSQL
For Each conSQL In oPKG.Connections
If conSQL.ProviderID = "SQLOLEDB" Then
conSQL.DataSource = DTSGlobalVariables("strSQLServerName").Value
conSQL.Catalog = DTSGlobalVariables("strSQLServerDB").Value
conSQL.UserID = DTSGlobalVariables("strSQLServerLogin").Value
conSQL.Password = DTSGlobalVariables("strSQLServerPassword").Value
End If
Next
I just want to build a similar DTS package with the global variable strSQLPassword "hidden"
-
Try setting the Password property of the connection instead.
This is 'hidden', and can be set in a disconnected edit.
Sean -
There are too many connections in the DTS package. I work know on the test server(with user, password, etc different from production server). I want to change only those global variables (server, database, login, password, etc) when we move the DTS to the production server.
-
The only other way is to pick the values up from an ini file.
You can put nt file restrictions on the ini file to sort of hide the text.
Use the read config task to do this.
------------------------------
The Users are always right - when I'm not wrong! -
We use a heavily restricted .INI file that the users can't see.
However, it appears that all your activity is between SQL Servers. Why not take advantage of trusted connections? Your services would have to use domain logins to access other servers but that hasn't been a problem for us.
-
the .ini file worked fine.
10x a lot
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply