Where you aware of this? Hot Fixes are cumulative
, meaning that each released hot fix includes those released prior to it.
It makes perfect sense to me. You don't want 6 different code bases to maintain, each with different hot fixes installed and then try to merge them once a year for a service pack. I couldn't imagine the various permutations, especially if you dig through the list of hot fixes for SQL Server 2005. By the last list I've seen, there have been 29 different builds release, possibly more.
However this is important for those of you that are thinking of applying a hot fix to your server. In fact, it's rather important that you are aware of what to test. If you apply HotFix 7 to fix some issue and Hot Fix 4 changed some behavior that exists in your application, then you should be regression testing the behavior for Hot Fix 4.
Which means that Microsoft needs to do a better job of linking all Hotfixes to all previous hot fix changes that are included. When I look at the latest Hotfix rollup for SP2 (build 9.0.3152), I should see a list of changes.
And I do. All the changes are linked to their Bug number and a description. I'd like to see these linked to other KB articles and those hotfixes as well, but this is a start. If I look at a pre-SP2 hotfix, like FIX: A "17187" error message may be logged in the Errorlog file when an instance of SQL Server 2005 is under a heavy load, I don't see previous HotFixes linked or included. Which means that if I were possibly affected by a previous fix, I might be confused.
We all need to be sure we document carefully which patches and fixes we apply to servers, but Microsoft needs to be sure they give us the information about what is changing as well. I don't expect separate fixes that aren't included in the core code branch, but I do want to know what I'm applying to my server.