Cart before the horse

Last week, a fix for SQL Server 2008 SP1 CU #4 was quietly slipped into the CU4 download page.  CU4 was build 10.0.2734, but you could have easily grabbed 10.0.2740 from the same download page without realizing it.  Out-of-band public fixes issued with little fanfare have been very rare since the Service Releases team instituted the current servicing model, so this always raises some eyebrows.  The fix was eventually documented in KB #976761, but it was nearly a week after the files were first made available to customers.  A user complained about the specific incident:

#508983 : SQL Server 2008 Service Pack 1 Cumulative Update 4 Hotfix to Version 10.00.2740.00

At around the same time, I wrote a lengthy blog post about the situation.  Basically, it's a bad idea to put files in front of customers without first telling them what those files are and what issue(s) they fix.  I realize the delta between 2734 and 2740 is not that great, and as it turned out, the knowledge gap only existed for a short period.  But in the meantime, if 2734 is what I approved in my test or QA environments, my deployment team better be getting 2734 and not 2740 from the download page for deployment to production.  Without sufficient documentation on the CU #4 page to guide them, some users are getting a build that is not the CU #4 that was advertised prior to November 4th.  I think the Connect item is quite targeted at this specific incident, but this should be a general criticism of the servicing model in general: documentation is always at least as important as the documented files and fixes.  I filed two separate issues to hopefully bring some visibility to this problem and prevent a repeat:

#509152 : Servicing model : release documentation about fixes before the files themselves

#509148 : Servicing model : better document deltas between concurrent cumulative updates

Ever want to keep non-default settings in new query windows?

I would like to see new query windows inherit certain properties from the currently focused editor window (for example, results to text, show execution plan, etc).  I'd settle for a context menu when you right-click an editor window, something like, "open a new query editor window with the same properties as this one."  Obviously someone will have to come up with a shorter term than that, but hopefully you get the drift.  

#508776 : SSMS : Have new query window inherit certain properties from existing window

Some suggestions from Ola Hallengren

Ola Hallengren has collected several Connect items over time that would make some of the free solutions he provides us with (thanks Ola!) work much more smoothly.

Rebuild an index partition online – #252433

Statistics on the partition level – #328093

MAXDOP option in DBCC CHECKDB – #468694

CHECKCONSTRAINTS option in DBCC CHECKDB – #508837

Continue SQL Server Agent T-SQL job step execution after an error – #244855

Include output files in SQL Server Agent Job failure notification – #293041

Startup parameters can be ignored

Erland complained way back in 2005 that when you enter certain startup parameters, you may think that they are in effect, but in fact they are not.  The issue was re-opened recently as Microsoft originally closed it as "Won't Fix," but several people have been bitten since.

#125567 : Leading spaces not stripped from startup parameters

Better timeout handling

Erland also recently made two suggestions about how timeouts are currently handled.

#508883 : Expose CommandTimeout in the connection string and also make it settable in the registry

#508884 : Start a path to move to a default for CommandTimeout to be 0