1

I'm looking at the Microsoft SQL Server 2016 Builds (see that section heading). The list of builds is given in build number order. That is, at the top of the list is the "highest" build number, and each subsequent row has lower build number than the one before.

However the release dates don't correlate with this. So here are 5 rows, for example:

  • Build 13.0.5081.1 - released 14/08/2018
  • Build 13.0.5101.9 - released 9/07/2019
  • Build 13.0.5102.14 - released 11/02/2020
  • Build 13.0.5149.0 - released 30/05/2018
  • Build 13.0.5153.0 - released 17/07/2018

The general sequence for builds around this time comes from 2018 - and then we have those 2 odd rows, from 2019 and 2020 and then back to the general sequence from 2018.

If a cumulative update is supposed to contain all prior cumulative updates, then how could that last build (in the 5 above) have contained the updates from the two builds from 2019 and 2020? (Oops - only just noticed the first line is from Aug, which is after the 4th and 5th lines too!)

If I had installed the 4th and 5th builds at the time of their releases (in May 2018 then July 2018), and then that 1st build gets released in Aug 2018 - would I automatically have had those changes incorporated already? If so, what was the point of issuing an older build number?

Another example

Here is another example that just makes no sense to me.

enter image description here

First, the RTM is dated June 2016. Then the first cumulative update - CU1 - is dated July 2017, which is 10 months after CU2 was released in Sep 2016. Huh?

And read the text at the bottom - "After certain Cumulative Updates, Microsoft released a Service Pack for SQL Server, which contains the entire previous fixes, Cumulative Updates, and hotfixes". Huh again? Note SP1 was released November 2016 and a full 7 of the 9 cumulative updates - correction, "previous ... Cumulative Updates", according to the caption - were released in 2017 after the Service Pack.

Table is from MSSQLTips.

Improve this question
1

2 Answers 2

Reset to default
1

Build 13.0.5101.9 - released 9/07/2019 is https://support.microsoft.com/en-us/help/4505220/kb4505220-security-update-for-sql-server-2016-sp2-gdr-july-9-2019

Build 13.0.5102.14 - released 11/02/2020 is https://support.microsoft.com/en-us/help/4532097/kb4532097-description-of-the-security-update-for-sql-server-2016-sp2-g

These are General Distribution Release (GDR) builds, intended to be installed by all customers running the affected Service Pack level.

Basically, those are critical patches for SQL 2016 SP2 which don't require installing any of the Cumulative Updates.

The relevant fixes would also have been included in the next CU, and probably available as a hotfix for the current CU.

As for the build numbers, GDR is a seperate branch from CU. It's tricky to apply a single build number system to a branched codebase, but the strategy appears to be that the GDR build numbers are placed between the common root build number (SP2) and the first CU (SP2 CU1).

if I upgrade my system to 13.0.5149.0,

That's CU1, and once you are on the "CU Train" you must apply subsequent CUs to get fixes. That's why the KB's say

To apply this update, you must have SQL Server 2016 SP2 or any SQL Server 2016 SP2 GDR release through this SQL Server 2016 SP2 GDR installed.

Improve this answer
2
  • "The relevant fixes would also have been included in the next CU"... next - in date order, or build number order? If date, then why give those builds build numbers that put them years earlier in the chronology of releases? If by build number then why release them years after the subsequent CU addressed the issue anyway? Thanks, your answer helps clarify how they are different - but I'm still not sure why they are given build numbers that slot them into the list years or months earlier.
    – youcantryreachingme
    Dec 15, 2020 at 0:05
  • PS - if I upgrade my system to 13.0.5149.0, for argument's sake, then it has a higher build number than the 2 builds you linked but was release at least 1 year before either of the builds you linked - so it is not clear to me whether the builds you linked are included in my upgrade or not. Hope that clarifies why the disparate numbering is confusing.
    – youcantryreachingme
    Dec 15, 2020 at 0:07
0

Prior to 2017 version of SQL Server, there was Service Packs (SP). And Microsoft released Security Updates for every SPs and RTMs.

For example, in this particular situation builds with numbers 13.0.5081.1, 13.0.5101.9 and 13.0.5102.14 are Security Updates for SQL Server 2016 SP2 GDR.

enter image description here

And if we'll look upper on the patch list, we'll see the same Security Updates with the same release date for Cumulative updates also:

enter image description here

Related to your second question, dates on your list are incorrect. You can review patch list by yourself on below-mentioned URL:

https://sqlserverbuilds.blogspot.com/

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.