• Steve Jones - SSC Editor (1/28/2014)


    Good points, Aaron, and I agree with you that I want CUs and quality has been good. However the caveats about support, and the fact that bi-monthly is quite fast, mean that this is an issue for support.

    Sure, bi-monthly is too fast for some. But annually is also too fast for some, so how do you really meter those to not be "too fast"? Consider too that for someone really dying for a specific fix, even two months is too long. I like that every other month gives me the ultimate flexibility: I can install every single one, I can wait until two, three, six, seven or 18 have accumulated, or I can wait for a service pack.

    Steve Jones - SSC Editor (1/28/2014)


    Personally I'd also like to see the CU pages include all previous fixes from the last SP/RTM so that people are aware of what's included. They are cumulative, but it's easy to forget that previous fixes are included.

    I think you may be onto something here. The only wrinkle is that someone then has to maintain that additional set of information, and that takes time away from fix development, regression testing, etc. That's not my argument, because you and I both know that that's either a simple copy & paste or (hopefully) a slightly different query to get the list at KB generation time, but that's what their argument will be. In any case, if people are reading closely enough that they see the warnings about regression testing etc. then they should also see the message about the cumulative nature of the updates:

    Because the builds are cumulative, each new update release contains all the hotfixes and all the security updates that were included with the previous <major version> update release. We recommend that you consider applying the most recent update release.

    I included the last sentence, because I find these articles quite two-faced. Here they recommend the latest cumulative update, but earlier in the document they say:

    This cumulative package is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems. The updates in this package may receive additional testing. Therefore, if you are not severely affected by any of these problems, we recommend that you wait for the next SQL Server 2008 service pack that contains the hotfixes in this package.

    I'm so torn; I don't know which recommendation to believe.