I have a problem. My school's databases are only accessible locally. So when I work from home or without an internet connection, I need to switch out the connectionString in my web.config to reflect a local database.
Is there a way to have two seperate connectionstrings, where one is used if the other is unavailable? Also, can I automatically mirror the first one to my local DB if it's available?
I should mention; this is a Web Forms project using .NET 4.0
Common use case "to maintain separate db connections" is to have 1 web.config with multiple configuration folders in your service hosting project.
Basically, your web.config should have connectionStrings section to reference each configuration environment (Dev/Local/QA/Prod):
<connectionStrings configSource=".\Config\Dev\connectionStrings.config" />
I don't believe this is possible to do directly, options could include:
1) Have a flag set either in config or elsewhere to signify the environment you are working in
2) Have a custom method for retrieving the connection string, this could then potentially catch a failed db connection and try again with the other string (you could also save the appropriate string in session for connections after the first one)
Related
I have a Silverlight application using Entity Framework. When I add a Data Connection in Server Explorer (Visual Studio 2010) I provide the “alias” for my database as the Server Name. After testing the connection and clicking OK, the connection appears under Data Connections list, but it is not listed under the “alias”. It appears listed as “ComputerName\Instance.DatabaseName.dbo”. That in itself is not a problem, but when I generate my entity classes, the connection string that is added to the web.config file lists the “ComputerName\Instance” as the server, rather than the “Alias”. This is not a problem for me, but when other developers pull my web.config file out of source control they can’t connect to their local copy of the database without changing the web.config file. It really isn’t a big deal, but it is annoying. Does anyone know how to get it use the Alias name all the way through?
Thanks,
Martin
It should be enough to modify connection string in web.config after you generate your entity model.
I've faced a bit strange problem. There is a site client would like to duplicate on another domain name. Site is built on ASP(yes, old v1 ASP :( ) with SQLServer. Problem is that all the database operations, including connection information is compiled into a DLL library.
Is there a way to some how intercept, override or workaround this?
Platform:
Windows 2000 Server
SQLServer 7
ASP v1 (VisualBasic)
What a nightmare...
If you have control over the new database server, and the connection string references the database server by name, you could add a line in the hosts file which points the name of the old server to a new ip address. Then you still have to create a user with the same password on the new database server.
Yes! However, your new database name MUST be smaller or equal to the length of your old one. Simply open up the vb6 .dll in any Hex Editor and search and replace. Make SURE you do not change the length of the DLL or shift any bytes around.
Failing that, add a hosts entry to windows to redirect the connection.
Could it be that the application uses a DSN definition for the connection?
In Control Panel -> Administrative Tools open ODBC Data Source Administrator. Have a look at the System DSN tab. Does there seem to be anything listed there that is related to the application?
Before you hack your DNS or rename the server, be aware that the SQL Server client supports aliases specifically for this scenario: How to: Create a Server Alias for Use by a Client.
The SQL 2000 tool for configuring an alias is the Client Network Utility.
Do you have any configuration options at all from asp? Even dbname or the such? If so you might be able to use two separate servers for IIS and use a single db server. I'm afraid you might need to find the source or the guy who wrote it.
If you could figure out the connection string or DNS you might be able to do something.
You could write your own passthrough ODBC provider.
I used to have a dts that had a sql server authentication connection. Basically, the userid password is stored in the package itself. Now, when I go to SSIS, the password is not getting stored to the package. I saw SSIS Connection Manager passwords when I googled the problem, but no one seems to have given a good resolution.
You can store the password in the configuration string by going to properties and adding password=yourpassword, but it's very important to put a space after the ; on the line before password and after the ; on the password line, as shown below:
Data Source=50.21.65.225;User ID=vc_ssis;
password=D#mc317Feo;
Initial Catalog=Sales;
Provider=SQLNCLI10.1;
Persist Security Info=True;Auto Translate=False;
Application Name=SSIS-PKG_CustomerData-{2A666833-6095-4486-C04F-350CBCA5C49E}IDM11.Sales.dev;
That answer points to this article: http://support.microsoft.com/kb/918760
Here are the proposed solutions - have you evaluated them?
Method 1: Use a SQL Server Agent proxy account
Create a SQL Server Agent proxy account. This proxy account must use a credential that lets SQL Server Agent run the job as the account that created the package or as an account that has the required permissions.
This method works to decrypt secrets and satisfies the key requirements by user. However, this method may have limited success because the SSIS package user keys involve the current user and the current computer. Therefore, if you move the package to another computer, this method may still fail, even if the job step uses the correct proxy account.
Back to the top
Method 2: Set the SSIS Package ProtectionLevel property to ServerStorage
Change the SSIS Package ProtectionLevel property to ServerStorage. This setting stores the package in a SQL Server database and allows access control through SQL Server database roles.
Back to the top
Method 3: Set the SSIS Package ProtectionLevel property to EncryptSensitiveWithPassword
Change the SSIS Package ProtectionLevel property to EncryptSensitiveWithPassword. This setting uses a password for encryption. You can then modify the SQL Server Agent job step command line to include this password.
Method 4: Use SSIS Package configuration files
Use SSIS Package configuration files to store sensitive information, and then store these configuration files in a secured folder. You can then change the ProtectionLevel property to DontSaveSensitive so that the package is not encrypted and does not try to save secrets to the package. When you run the SSIS package, the required information is loaded from the configuration file. Make sure that the configuration files are adequately protected if they contain sensitive information.
Method 5: Create a package template
For a long-term resolution, create a package template that uses a protection level that differs from the default setting. This problem will not occur in future packages.
I use a variable to store the entire connection string and pass it into the ConnectionString expression. This overwrites all settings for the connection and allows you store the password.
The designed behavior in SSIS is to prevent storing passwords in a package, because it's bad practice/not safe to do so.
Instead, either use Windows auth, so you don't store secrets in packages or config files, or, if that's really impossible in your environment (maybe you have no Windows domain, for example) then you have to use a workaround as described in http://support.microsoft.com/kb/918760 (Sam's correct, just read further in that article). The simplest answer is a config file to go with the package, but then you have to worry that the config file is stored securely so someone can't just read it and take the credentials.
Please check the configuration file in the project, set ID and password there, so that you execute the package
It happened with me as well and fixed in following way:
Created expression based connection string and saved password in a variable and used it.
Try storing the connection string along with the password in a variable and assign the variable in the connection string using expression.I also faced the same issue and I solved like dis.
Check the text contents of the connection manager file itself, the password field might be configured in the Project.params file, in which case entering the password into the connection manager window will cause it to not save.
Here is a simpler option that works when I encounter this.
After you create the connection, select the connection and open the Properties. In the Expressions category find Password. Re-enter the password and hit Enter. It will now be saved to the connection.
There is easy way of doing this. I don't know why people are giving complicated answers.
Double click SSIS package. Then go to connection manager, select DestinationConnectionOLDB and then add password next to login field.
Example: Data Source=SysproDB1;User ID=test;password=test;Initial Catalog=ASBuiltDW;Provider=SQLNCLI11;Auto Translate=false;
Do same for SourceConnectionOLDB.
I'm wondering what techniques you use to store the database credentials for your application. I'm specifically concerned with java webapps, but I don't think there's any need to limit the questions to that.
things to consider:
Do you use property files,xml configs, other?
Is it bundled into your application(ie in a jar file) or stored seperately on the file system somewhere?
Is the password encrypted? If so, what encryption scheme do you use?
Since you're leaving the question open to platform, I'll add that database credentials for .NET apps are stored in the web.config file. From version 2.0 and above, there is a specific ConnectionStrings section that allows for easier programmatic access to the connection string.
In addition to having IIS automatically block direct requests to the web.config file by default, you can also use an IIS command to encrypt the ConnectionString section of the web.config file. This encryption is machine specific, adding to its strengths, and the .NET runtime will also decrypt the connection string on the fly when you access it, so there is no need for additional coding in your application to work with it.
With Java, database connection pools should be passed into webapps by the container. This is in the standard declarable in WEB-INF/web.xml as resources. The same applies to mail sessions and other external resources that may vary from installation to installation. Look up JNDI for more information on this)
The nice part with this is that the application doesn't care about how to actually connect to anything outside. It will not see any passwords, because the container itself will use them.
In tomcat this is configured either from context files (e.g.) in conf/Catalina/localhost/ , conf/server.xml or - preferably only for dev environments, from the webapps META-INF/context.xml. Other environments have their own configuration location or application.
The encryption of passwords actually depends on the container. Tomcat stores them in plaintext, but the application itself won't see it. I don't know about the mechanics in other environments.
On the Microsoft stack, things can be very nice.
You create a network user account in Active Directory with almost no permissions. You configure IIS to run your webapp as that user. You grant that user read access to the web folders and files on the disk. You configure SQL Server to grant that user read/write permissions on the tables you want. And in the connection string, you instruct the db client to connect as the user account which the webapp is currently being run as.
There is only one actual user account, although it is visible in multiple places. This user account has extremely limited permissions. There is no storing passwords anywhere, even if encrypted. There is no configuration that has to be done in code for this to work (it's all in setting up the permissions).
Depends on the app server.
I usually use JNDI lookups for the data source, so credentials are stored on the app server that handles the connection pool. No need to put anything other than the JNDI name in configuration that way.
Yes, the password is encrypted on WebLogic.
On Tomcat things can be dicey. Connection info is in META-INF/context.xml, which means plain text for the password. I only do that for development, never in production.
In Django, the credentials are in your settings.py configuration file. Since this is not generally kept in your /var/www/ directory tree, it's very safe.
Also, a single Django application may be used (and reused) for many web sites or web servers on the same host, each with it's own distinct settings. So the settings.py configuration is not bundled with the app, but is part of a single deployment of the app.
For asp.net:
I store global parameters such as the connection string and repository paths in the Registry and then a reference to the registry entry in the web.config.
The main reason being that I often find I have to write a stand alone executable to run background tasks and other automated features that require access to the same parameters. Therefore keeping everything that is truly global in one easily accessible place makes for an easier life.
As stated before, no platform specified, and using some ideas from earlier answers:
I am considering a containerised application. You could store the password for the database in a file in the container. The first step of your application would be to establish the database connection, even before listening on web requests. With a successful db connection the file with the credentials is deleted and the variables containing the these, are removed. So when you start serving requests, the only thing that remains, is an open database handle to use from this moment on. If for any reason the database connection is lost, you simply quit and wait to restart the container, the credentials file will be there again.
Which of these are good places to keep your web app’s database credentials?
In a separate file in your source code
In a separate file on your web server host
In your database
None. The database credentials should never be stored
I have an SSIS Package that sets some variable data from a SQL Server Package Configuration Table. (Selecting the "Specify configuration setings directly" option)
This works well when I'm using the Database connection that I specified when developing the package. However when I run it on a server (64 bit) in the testing environment (either as an Agent job or running the package directly) and I Specify the new connection string in the Connection managers, the package still reads the settings from the DB server that I specified in development.
All the other Connections take up the correct connection strings, it only seems to be the Package Configuration that reads from the wrong place.
Any ideas or am I doing something really wrong?
The only way I was able to do this was to use Windows Environment Variables. You can specify things like connection strings and user preferences in environment variables, and then pick up those environment variables from your SSIS Task.
I prefer to use Server Aliases in the SQL Client Configuration. That way, when you decide to point the package to another SQL Server it is as simple as editing the alias to point to the new server, no editing necessary in the SSIS package. When moving the package to a live server, you need to add the aliases, and it works.
This also helps when you have a real painful naming convention for servers, the alias can be a more descriptive name than the actual machine name.
I didn't actually understand your question completely but I store my connection settings in a configuration files usually one for each environment like dev, production etc. The packages read the connection settings from the config files when they are run.
When you're creating a job to call the SSIS package, and you're setting up the step, there is a tabbed area. The default tab is where you set the package name, and the next tab over is where you can set the configuration file. Have a config file for each package, and change for the server (dev, test, prod). The config file can be put directly on the dev, test, and prod servers, and then point to them when setting up that job.
If u are using SQL Server Package Configuration then all the properties of the packages will come from SQL Server table - Please check that
SSIS security the way it stands is terrible. No one will be able to support things when I am out of the office. The job never reads from the configuration file...I give up. It only works when I edit the string in the Data sources tab. However the password gets lost if you happen to go into the job a second time. Terrible design, absolutely horrible. You would think that when you specify a xml file in the job step it would read the connection string from there that is defined, but it does not. Does this really work for anyone else?
Goto the package properties and set deployment True. This should work for what you have done.
I had the identical question, and got the same answer, i.e. you cannot edit the connection string used for package configurations hosted in SQL Server, except if you specify that the SQL Server connection string should be in an environment variable.
This unfortunately does not work in my dev setup, where two environments are hosted on the same machine. I ended up following Scott Coleman's approach as detailed on SQL Server Central [Free sign-up and a good site]. The trick is that you create a view to store your configuration settings on one central server, and then use the machine that connects to it to determine which environment is active.
I used that approach, but also used the User connecting to the environment to make a determination, because my test and dev setups run on the same SSIS instance, but as different user names. Scott suggests in the comments that the application name should be set, but this cannot be changed in the package execution job step, so it was not an option.
One other caveat that I found was that I had to add "Instead of" triggers to my view to do the inserts, updates and deletes for configuration variables.
We want to keep our package configs in a database table, we know it gets backuped with our other data and we know where to find it. Just a preference.
I have found that to get this to work I can use an environment variable configuration to set the connection string of the connection manager that I am reading my package config from. (Although I had to restart the SQL Server agent before it could find the new environment variable. Not ideal when I deploy this to Production)
Looks Like when you run an SSIS package as a step in a scheduled task it works in this order:
Load each of the Package Configs in the order they appear in the Package Configuations Organiser
Set the Connection Strings from the Data sources tab in the Job Step properties of the Scheduled Job
Start running package.
I would have expected the first 2 to be the other way around so that I can set the data source for my package config from the scheduled job. That is where I would expect other people to look for it when maintaining the package.