isual Studio provides convenient design-time wizards to define static database connection strings that you can store in your settings files. Storing connection strings in configuration files means you can update the connection string without having to recompile or redeploy the host program, although it does require restarting the application. This article presents a dynamically configurable user control that lets you provide users with the capability to change the connection parameters themselves. You have complete control—letting them change all or only some portions of the connection string.

Developers building database applications often encounter many of the same common scenarios.

• Arbitrary Server Name. You're tasked with delivering an application that must install on the customers' servers, but you can't know the server name in advance. Your product creates a database on that server with a specific, constant name. Further, your application relies on a predefined "application user" account with specific permissions. In this case, you never want to expose the username, the password, or the database name to the user. In this scenario, a customer at company X would have a database of the same name as a customer at company Y, each on their own server (whose names are arbitrary and unknown to you). To make this work, you must either write a custom installation program, which prompts for the server name during the install, or add logic that requests the server name the first time the application runs. The username, password, and database name are all invariants in your program and, in fact, you do not want to reveal these to casual users.
• Individual Login Support. Your application supports individual logins for every user. So at some point in your program you need to ask users for their names and passwords. Depending on the application and the requirements, you may choose to ask every time the program runs, or just the first time the application is run, or you might opt to allow users to choose whether the program should remember their credentials.
• Configurable Development Environments. During development and testing, you want to be able to switch between your development database and a test database. (Or similarly between a development server and a test server.) Or perhaps you have multiple databases, each configured differently to test different aspects of your application.
• Support for Privileged Users. Your application is sophisticated enough that it differentiates between ordinary users (ordinary in name only; these are the folks who actually accomplish work with it!) and privileged or administrative users. The latter group needs to have the ability to select a different database or server in addition to entering their usernames and passwords, whereas ordinary users need only to input their usernames and passwords.

Orthogonal to the scenarios above, there are some additional considerations, such as always omitting the password from a stored connection string for security reasons; testing the database connection after users provide parameters; allowing Windows authentication vs. SQL Server authentication; connecting to different database systems (such as SQL Server or Oracle), and so forth.

Creating a custom login form for each proprietary application is tedious, boring, and error prone; instead, you can build a generic control suitable for any application, and configure it with just a few lines of code to customize it according to an application's needs. The control should be flexible enough to handle all the considerations listed in the various scenarios, and it must be easy for developers to use.

The ConnectionStringManager control described in this article fulfills those conditions. When you drop it on your Windows Form, you need only add OK and Cancel buttons and hook up their event handlers to have a complete database login panel. The output of the control is simply an updated connection string that you may then use to establish your database connections, store in the user's settings, and so on.