Visual Studio .NET Design-Time Features

Questions That Should Be Asked More Frequently

1. Q. When I add a data connection to Server Explorer, I can shut down and restart, and Visual Studio .NET will remember my settings. Where does Server Explorer store those settings?

2. A. Server Explorer stores its settings on a per-user basis. If multiple developers use Visual Studio .NET on the same machine, their Server Explorer settings will be stored separately, in a file named (Default View).SEView. This file resides in a subfolder in that user's Settings folder. That means that unless you formatted your drive to use NTFS, passwords in Server Explorer data connections are readily available to anyone who can access that machine.

3. Q. I'm building an application that will use SQL Server as the back-end database. Should I use standard or integrated security?

4. A. This is a complex issue. The appropriate solution might depend on the architecture of your application and how you choose to manage security on your SQL Server database. I prefer using integrated security in two-tier applications and standard security in multi-tiered applications.

   Using integrated security prevents you from having to prompt the user for credentials or hard-code them into the application. Using standard security in a multi-tiered application (where your data access code runs in a Web service or COM+ component) lets you take advantage of connection pooling. In this architecture, the component determines the user's credentials. That might sound like a cop-out, and in some ways it is. However, I think it's also a totally valid solution.

   What if the only point at which your middle-tier component validates the user's credentials is in the data access code? If the database says that the user doesn't have access, that generally means you didn't want the user to access this feature of the middle-tier object in the first place. If that's the case, you're wasting time and might be compromising security by letting the user run the code in the component that precedes the call to connect to your database.

   You're better off setting up security so that the user must have the proper credentials to access the component. You can then have the component use a standard connection string. Because all clients will use the same connection string, your component will be able to use all of their connections with a single pool. If all of your users connect to your database using different credentials, you're not taking advantage of pooling.

   For more information on using SQL Server with standard and integrated security, see SQL Server Books Online.

5. Q. For security purposes, the Connection that I'm using in my application has limited access to my database. However, I still want to take advantage of some of the database administration features in Server Explorer, such as creating or modifying the structure of my tables. How do I balance the security of the connection I'm using in my application at run time with the functionality I want to use at design time?

6. A. Use multiple connections in Server Explorer. You can simply add a new connection to Server Explorer that uses an account with more database privileges. If you don't actually use the connection in your application, it won't be included in your application.