New SERVERPROPERTY Options to Help Phase Out @@VERSION

Aaron Bertrand

Published On: October 22, 2015

Categories: SQL Server 2016, SQL Server 2014, SQL Server Builds 2

As I mentioned in a previous post, the SQL Server team is interested in exposing more descriptive information about the patch level of a SQL Server instance. They described their initial plan in the post, "What build of SQL Server are you using?" I objected almost immediately, due to the fact that changing the shape of @@VERSION could cause backward compatibility issues for any code that parses that information to determine the build or other information. I felt strongly enough about this that I turned to Connect, asking for a DMV to expose this information instead:

If you voted for this item, thank you, I appreciate your support. I have not given up on my idea, but as of the latest round of updates for SQL Server 2014, @@VERSION still exposes this disruptive information. Which will break code like this:

IF @bitness = 'X64'
  PRINT 'X64'; -- do something for X64
  PRINT 'X86'; -- do something for X86

64-bit instances of 2014 < SP1 CU3 or < RTM CU10 will enter the branch for x64, while those with the latest updates will actually enter the branch for x86. Now, I am not advocating code like this or trying to justify not revisiting it, but I have it on good authority that several SQL Server environments will have a lot of code to update that matches this type of pattern.

On the plus side, they have added additional locations to retrieve it; namely, four new server properties, documented under the section Method 4 in KB #321185 : How to determine the version and edition of SQL Server and its components:

  SERVERPROPERTY('ProductVersion'),         -- pre-existing build string e.g. 12.0.4427.24
  SERVERPROPERTY('ProductLevel'),           -- what major branch? RTM / SPx / CTP
  SERVERPROPERTY('ProductUpdateLevel'),     -- which cumulative update #?
  SERVERPROPERTY('ProductBuildType'),       -- is this a GDR / QFE / COD update or hotfix?
  SERVERPROPERTY('ProductUpdateReference'); -- KB article describing current patch level

(ProductBuild also seems to be a new property, but it isn't documented that way, and all it does is produce the 3rd octet of ProductVersion, e.g. for 12.0.4427.24, ProductBuild returns 4427. The first two octets can be returned using ProductMajorVersion (12) and ProductMinorVersion (0).)

Some sample results from some of the systems I had handy at the time of writing (knowing that many of these builds would simply return NULL for most of the properties, and omitting the unimportant 4th octet of ProductVersion):

(hover for info)
ProductLevel ProductUpdateLevel ProductBuildType ProductUpdateReference
11.0.3128 SP1 <NULL> <NULL> <NULL>
11.0.5058 SP2 <NULL> <NULL> <NULL>
11.0.5636 SP2 <NULL> <NULL> <NULL>
12.0.2000 RTM <NULL> <NULL> <NULL>
12.0.2556 RTM CU10 <NULL> KB3094220
12.0.4100 SP1 <NULL> <NULL> <NULL>
12.0.4419 SP1 <NULL> <NULL> <NULL>
12.0.4427 SP1 CU3 <NULL> KB3094221
13.0.600 CTP <NULL> <NULL> <NULL>

As a note, @@VERSION has been altered in this way going back to SQL Server 2008 RTM, but this didn't get put into SQL Server 2014 until the most recent CUs. For example, the SQL Server 2012 build above, 11.0.5636, has a service pack and an on-demand hotfix applied. While that build of SQL Server has not been updated to support these new SERVERPROPERTY arguments, its @@VERSION output shows that this instance has Service Pack 2 installed, has all of the fixes from Cumulative Update #8 (either by installing that update manually, or by virtue of installing a later GDR/QFE/COD hotfix), and that it has the on-demand connection pooling hotfix from KB #3097636:

Microsoft SQL Server 2012 (SP2-CU8-OD) (KB3097636) – 11.0.5636.3 (X64)
    Sep 18 2015 18:43:26
    Copyright (c) Microsoft Corporation
    Developer Edition (64-bit) on Windows NT 6.3 (Build 10240: ) (Hypervisor)

If this change to SERVERPROPERTY gets back-ported to SQL Server 2012, then for any new builds, the information would also be exposed there.

Going forward, the new SERVERPROPERTY output is how you should be deriving this information. This is especially true for any new code you think you might write specifically for extracting information out of the large @@VERSION string, because the only thing that will stay consistent about that is that it will keep changing. I'm not entirely happy about that, but I think the decision has been made.

Aaron (@AaronBertrand) is a Data Platform MVP with industry experience dating back to Classic ASP and SQL Server 6.5. He is editor-in-chief of the performance-related blog, Aaron's blog focuses on T-SQL bad habits and best practices, as well as coverage of updates and new features in Plan Explorer, SentryOne, and SQL Server.