With SQL Server 2005, Microsoft introduced a very useful feature called the DAC. DAC stands for "dedicated administrator connection"… you can read about it here, but essentially, it allows you a single connection into the server with priority resource allocation – so you can actually get in and kill a rogue process that is otherwise taking over the server. On its own this was a fine acronym choice, but I don't think it was visible enough to some other teams within SQL Server – well, one team in particular. We'll come back to this in a minute.

"PB & J & D & M & F"

In SQL Server 2008, Policy-Based Management (PBM) was originally introduced to us as Dynamic [edit: Declarative] Management Framework (DMF). This doesn't really have a lot of impact, as it was never publicly released as DMF (at least not that I remember), but the change was made late enough into the cycle that all of the namespaces around PBM still contain the old acronym, for example Microsoft.SqlServer.Management.DMF.PolicyStore. This tends to invoke questions about what on earth DMF means – and a lot of people think it must have something to do with Dynamic Management Functions. Which don't actually have an official acronym, as far as I know.

"DATETIME_WHAT?"

SQL Server 2008 also introduced a new DATETIME data type which they called, for lack of any creativity whatsoever, DATETIME2. I suspect that the person in charge of that one came over from Oracle, and that was the first decision he/she was forced to make. Many of us clamored for a better and more meaningful name, following established conventions (they didn't name BIGINT "INT2", did they?), for fear that we were only a few versions away from DATETIME3, XML2 and VARCHAR(MAX2). But alas, the horrible name stuck.

"DAC, part too much"

In SQL Server 2008 R2 (in combination with Visual Studio 2010), they introduced a new development concept called a DAC. Does DAC sound familiar? It should; I just talked about it a few paragraphs ago. But that was a different DAC. Yes, you heard me right. THIS type of DAC (which stands for Data-Tier Application) allows you to package scripts and database changes together to ease deployment of complex database changes. You can read more about the DAC (and its associated DACPAC – a DAC package, of course) here. I complained about this quite loudly during the R2 beta, but it fell on deaf ears. Even Brent Ozar makes fun of the fact that DTA was already taken – not that that would have been a better acronym, obviously.

"Please help us name a server-less SQL Server"

Now with SQL Server Denali, they are struggling to come up with a name for their new "server-less SQL Server" feature, which will be included in the toolset currently known as "Juneau." Some background (lifted directly from the survey they're pushing today):

Thank you for your help in naming the new “server-less” feature.

What is it?

The SQL Server team is working on a new “server-less” execution mode of the SQL Server Database Engine. Designed to improve the user experience for database developers, Web developers, and Independent Software Vendors working on database code or embedding SQL Server into their applications, the improvement eliminates the need to install, configure, and manage a full server instance of SQL Server.

How it works?

In this execution mode, a SQL Server process spins up with your application or development tool – all you need to do is specify the right connection string. It runs as a user process and not as a service (it does not require a service to be installed and configured). In this mode, SQL Server will only accept local connections, and it will shut down automatically after the last connection is closed.

(I can't resist pointing out how the two headlines were obviously written by two different people… the second should be "How does it work?" not "How it works?" – but that is just my anal retentive grammar gestapo getting the better of me.)

Now, I've seen a demo of the feature, and it does appear to be quite useful – though I don't think it has ever been all that hard to install, configure and manage an instance of SQL Server Developer Edition. Anyway, it will allow you to develop your database locally, targeting whatever edition you like. So I was surprised when I got to the next page of the survey, and these were my options:

So, essentially, they're going to call it "SQL Server Express <something>," you just get to tell them what the <something> should be (or fill out "Other" of course). This makes very little sense to me. It either means that it has the same feature limitations as SQL Server Express Edition (so you can't really develop all of the features for any edition, such as partitioning for Enterprise), or it means that the limitations aren't there but people will be led to think that they are. In either case, it is a horrible name at best (if the latter is true), or a useless feature at worst (if the former is true).

My suggestion was "SQL Server Local Edition" – this implies what it is and, more importantly, does not imply what it isn't. Unless of course the intention is to truly only offer developers the features from Express Edition. In which case, one of the 7 names above is quite likely a better choice.

"It is not a TIMESTAMP!"

Yes, I pictured Arnold Schwarzenegger reading that headline. This is my favorite of all horrible naming blunders in the history of SQL Server. This data type violates ANSI standards and has absolutely nothing to do with date or time – in fact an alias type was introduced called ROWVERSION so that people would stop thinking that there was any correlation to a clock. Yet I can't recall how many times I've answered sad users who want to know why they can't use a simple WHERE clause to find all the rows with TIMESTAMP > yesterday. In 2007 I opened a Connect item (and I believe I had one in Ladybug, the bug reporting system that pre-dated Connect) to address the deprecation of this type:

• Connect #274333

And in the 2008 version of Books Online, they quietly announce in the rowversion (Transact-SQL) topic that the "timestamp syntax is deprecated." Hooray! Except that to this day (and including the SQL Server 2019 release), sys.types still uses TIMESTAMP, not ROWVERSION. And if you create a table using ROWVERSION syntax, then script it out using Management Studio, the resulting script will contain the name TIMESTAMP. So, two full versions since the deprecation announcement (and at least four full versions since they admitted their blunder), and not a line of code appears to have changed.