January 20, 2010 | SQL Server

Mis-steps in the publication of Cumulative Updates

It used to be very difficult to obtain hotfixes for SQL Server (sometimes even to learn about their existence), and they were often unsupported.  They have made extremely great strides in this area, and in general, I find the new procedure much more convenient : just go to the KB article, select the fix(es) you want, and you get an almost immediate e-mail with download links and brief instructions.  No longer do I have to raise an issue with customer support and prove to them that I am both affected by the issue and responsible enough to handle the patch correctly.  But there are still some holes in the process.

1. Trying to be "smart" about platform

The hotfix download page determines your platform and language and offers you the patch files for your current local environment.  While this might be a good idea in some cases (such as client patches), for SQL Server this makes no sense at all.  This methodology assumes that I am downloading patches only for my immediate machine, when in reality I am usually downloading for a variety of instances, many of which are not even on the same subnet as my workstation.  Add to this the fact that in my experience the code just doesn't work – this is a pure x64 machine, and yet because I am using Firefox, the download page for every cumulative update thus far has limited my view to the x86 files.  It is only a minor piece of extra work to get access to the x64 files I'm really after (simply click on the "Show hotfixes for all platforms and languages" link), but ideally I'd like to see a setting where (via a cookie, or LiveID, or something) I could say "always show all platforms" or "always show both x64 and x86 files."  Or take away the "smarts" that hide the other platforms from me in the first place – presumably this is just a way to avoid actually documenting the files in sections, so silly people don't download files for the wrong platform.

2. Publication of correct files and filenames

While the screen shot will only highlight the repeating spelling error ("cumlative" vs. "cumulative") that has afflicted the last few cumulative updates, there was a pretty serious mistake in this most recent CU where the SP1 download actually contained the patch for RTM.  Now a lot of people are extracting the file, trying to run it against their SP1 instances, and it finds there is nothing to update.  Rather than assume a simple case of mistaken identity, many will assume that either the patch or their environment is broken.  Right now you'll notice in the screenshot below that the core file has been pulled from the download page, so they are fixing the problem – in fact it has probably been corrected by the time you are reading this.  But why was it wrong in the first place?  Are the download packages not tested even once before they are published?

3. Being vague about the included files

There are always several files in each CU download, and they are not explained anywhere either on the download page or the original KB page.  What is a "SapBi" or "RB2ClickOn" file?  Do I need it?  Who knows? I really believe that for each CU they need to have some section on the download page describing the use case where you would want to download any of the smaller files individually.

The proof

The proof is, as they say, in the pudding.  You can see the highlighted areas in the screenshot from the points above (click to embiggen):

What to do?

Without direct interaction with those involved, I am not sure what else we can do to make corrections to these processes.  The feeling of a CU is already inherently "rushed"; then when the files are published clearly without testing or attention to detail, that rushed feeling is exaggerated.  I have commented about this problem on Connect and in a previous bog post.  I've also stressed the need to fully document CUs before releasing them (but somehow left out the "testing" part).  After today's incident, it is obvious there are still some items that have room for improvement.

At least from the outside, they look like relatively simple things to fix.  Fixing them would lead to a lot less confusion among the customer base, and a lot more confidence in the general approach and attitude toward releasing updates.  A lot of that is just about better communication.  For example, while they were fixing this problem, they did not make any announcements whatsoever; they simply pulled the core files from the download page.

9 comments on this post

    • AaronBertrand - January 20, 2010, 9:59 PM

      Quick update: Bob Ward told us about a quick blog post on the snafu with the SP1 vs. RTM CU files:

    • Dan Shargel - January 21, 2010, 12:00 AM

      Thanks for the post.  I can't say how much this inspires confidence in MS that they push out RTM CU9 as SP1 CU6.

    • AaronBertrand - January 21, 2010, 12:08 AM

      Yep, and still waiting for the corrected files to be posted.  Hopefully the delay is because they are testing the downloads.

    • Glenn Berry - January 21, 2010, 1:19 AM

      Is embiggen a Canadian word?  I absolutely agree that someone should have at least tested the download packages before they were posted, and that Microsoft should document what the smaller packages are in more detail.

    • IL - January 21, 2010, 9:57 AM
    • AaronBertrand - January 21, 2010, 5:50 PM

      Glenn, no embiggen is not a Canadian word, I picked it up years ago from fark.com.
      IL, thanks for the update.

    • Richard - January 25, 2010, 5:07 PM

      I always thought that the Simpsons invented the word "Embiggen":
      "A noble spirit embiggens the smallest man."
      "I don’t know why; it’s a perfectly cromulent word."
      "He's embiggened that role with his cromulent performance."

    • Brian - August 31, 2010, 8:14 PM

      Did you ever figure out what the different downloads being offered were for?  For example, the "SapBi" or "RB2ClickOn" or "RSSharepoin" items?
      I suspect SapBi = some component that integrates SAP into SQL Server.
      I suspect "RB2ClickOn" = Report Builder 2 Click Once
      I suspect "RSSharepoin" = something related to either the SharePoint reporting services Add In  or the RSSharepoint dbs.
      I am trying to figure out if these are needed in addition to core DBMS update (which I suspect is just the Cumulative Update file with no other text appended to it).

    • Aaron Bertrand - August 31, 2010, 8:19 PM

      Nothing definitive that I have found, no.  I think your guesses are as good as mine, and unless you are obviously running the types of services they allude to, only the primary CU file is necessary.  (It should find those other components and update them as well, I would expect… those seem to be for specific, stand-alone things.)  If you have to ask what it is, you probably don't need it.  🙂

Comments are closed.