Along with the SQL Server, Database, Username and Password, don’t forget to include the Application Name in your connection string. It’s an optional parameter, but it can be a lifesaver.
Data Source=myServer;
Initial Catalog=myDB;
User Id=myUsername;
Password=myPassword;
Application Name=myApp;
Consider this example: There are multiple .NET applications running on a single web server. Each application shares a common SQL Server Server which is suddenly performing very poorly. You are tasked with determine which of the applications is causing havoc. You launch SQL Profiler and run a trace. Since you have included the optional parameter in your connection string, you may now filter the application specific queries and troubleshoot the problem far more effectively. If you hadn’t specified the application name, you would have some work ahead of you. In this case, all of the queries would have had a generic app name, .NET sqlClient Data Provider, and that isn’t very helpful, is it?
Do yourself a favor and be sure to add this practice to your coding standards…
by Charles Petzold
by Roy Osherove
Include Application Name in Your Connectionstring…
You’ve been kicked (a good thing) – Trackback from DotNetKicks.com…
[...] This post describes why you want to include your app name in the connection string to SQL Server. Since we use a general connection string object to feed us different strings, our object would have to be modified to require a application name argument, but still looks useful for future debugging work. [...]
Agreed – I was googling to try to find out/verify the name of this setting, so I already knew about it. Guess why I’m setting it now? Exactly because I’m doing some SQL Server profiling…
@Per – I’m glad you found the site (and the setting name.) Thanks for the feedback and validation.
A great secret of success is to go through life as a man who never gets used up.
This is extreamly good practice to include an app name. I work at software support for a company and constantly need to set app names on connection strings as the original developers just didn’t bother! We run 50+ sites across two SQL Server DBs (current & legacy) and tracing procedure calls from most sites is almost impossible without updating the live web.config (which is horrendeously bad practice!)
There are also instances of app names being duplicated across multiple sites thanks to copy + paste so as you can imagine, it can get pretty frustrating!
@Rob – Thanks for the comment. It’s really great to hear from folks who have been in the trenches and can really appreciate and endorse some of the tips I write about.
this is a great tip. i already used it for
???????? site.
Here’s another interesting use of Application Name:
I’m working with a group on a localization project, and the DBA uses this to set the locale string (e.g. “en-US”).
That way the locale setting is available, and localized strings can be returned, without having to pass in the locale with every query or stored proc.
@Kyralessa – That’s a very clever idea. Don’t change that Application Name!
[...] On the final tab, you can provide extra connection information like Application Name which can come in handy. [...]
show the application no
I hope people from work are reading this comment because that means they clicked on the link for this Blog in my email.
Make DBA smile set APPLICATION NAME in your connection string.
I am firm believer that this one setting can save an enterprise size company like ours many, many HOURS of time in a year, just from removing the time spent on figuring out where a SPID is coming from.
Thanks!!
Erik
MCDBA, MCITP
@Erik, I love your comment. Thanks for helping to spread the word – one email at a time.