There are only two hard things in Computer Science: cache invalidation and naming things.
— Phil Karlton
All things should be properly named. It makes it look like there was some thought behind the design and that we don’t leave the various settings to default.
I’ve briefly touched on this topic in the previous TSQL Tuesday: Coding Standards, but I cannot believe I’ve forgotten the one type of name I care about the most - the application name.
What’s my problem? 🔗︎
Whenever I’m trying to debug a problem using sp_whoisactive or Extended Events (XE) and I see either
Core Microsoft SqlClient Data Provider or
.Net SqlClient Data Provider, my blood begins to boil.
It means I’ll probably spend hours asking around to try and find the owner. Sometimes knowing the
host_name helps, but there can be a multi-purpose host that runs many applications - which one is having the problem?
The same applies to monitoring. If I want to monitor only activity from a single app, I need something to distinguish it by. And the
app_name is the perfect candidate.
But monitoring aside. If there is an error in your app and it takes a DBA to tell you, then you haven’t been handling errors well enough.
The least you can do is provide the
app_name as a traceback mechanism, so we can make you aware and fix the problem. Perhaps full-text search in source control or a documented overview of apps and owners (one can dream).
An app by any other name would perform as terribly.
— Shakespeare (probably)
The syntax is straightforward
You can even try it in SSMS - here’s an example from the blog post Scary Scalar Functions - Part Two: Performance where I want to track only XE from
app_name = MonitorXE.
You can check that it works with
SELECT APP_NAME() AS AppName.
Final thoughts 🔗︎
Everything should have a name, whether it’s an App, SSIS package, a script or your pet. I’ll leave the convention to you because naming things is hard.
Maybe apart from the “fireplace”, - that was lazy.
Thank you for reading.