Connect Digest : 2010-02-06

Upgrading a database with read-only filegroups

Earlier today, I complained that I should be able to upgrade a database with read-only filegroups.  In this case an upgrade from, say, 2000 to 2005 is blocked because the engine can't update the system schema / structure.  Since I am trying to protect the data, not the system schema, I think it should be okay that the engine ignores the read-only flag during the upgrade process.  The workaround is rather cumbersome : get exclusive access to the original database, mark the filegroup as read/write, backup, restore, then mark the filegroup as read-only.  Blecch.

#531630 : Should be able to upgrade a database with read-only filegroups

In testing this scenario against different versions of the engine, I also came across a couple of bugs in SSMS 2008 SP1 dialogs that deal with filegroups and the read-only flag:

#531643 : SSMS : issues scripting the disabling of read-only flag

#531645 : SSMS : cannot create new database with read-only filegroup

Updating statistics during RESTORE

Steve Jones wants to see updating statistics to be an optional part of a RESTORE operation:

#529760 : Update Statistics as Part of a Restore



NULLgarity wants filegrowth settings to be inherited from model instead of defaulting to 1MB when not specified.

#531593 : Change default behavior for FILEGROWTH argument in CREATE DATABASE statement



There is a lot to be said for sorting.  The other day I requested that the "Object Explorer Details" column header choices be ordered alphabetically instead of mosaically:

#531267 : SSMS : order Object Explorer Details column header context menu alphabetically

And a long time ago, NULLgarity also asked for the ability to sort grid results by clicking on column headers.  Ideally we would just get Excel integration into the results pane (I asked for that in #524769), but this would be a good consolation prize:

#127045 : "Results to Grid" Grid should be sortable by clicking column header


Bad error messages

And the other day, I highlighted several Connect items when I discussed some of the poor and/or vague error messages that come out of SQL Server:

When bad error messages happen to good people


Connect URLs

As for Connect itself, you may have noticed the shiny new URL format for Connect items, e.g.:*/

This overcomes the severely limited URL format that existed previously:*/

This format was not only far too long to be practical for services like twitter, but it also drove people nuts in newsgroups or e-mail, because it would often wrap and break.  Go vote for that item (either link will work!), as it is encouraging them to come up with an even shorter and more intuitive URL format that will do away with the need to use and the like to shorten Connect item URLs.

Aaron Bertrand

I am a passionate technologist with industry experience dating back to Classic ASP and SQL Server 6.5. I am a long-time Microsoft MVP, write at Simple Talk, SQLPerformance, and MSSQLTips, and have had the honor of speaking at more conferences than I can remember. In non-tech life, I am a father of two, a huge hockey and football fan, and my pronouns are he/him. If I've helped you out, consider thanking me with a coffee. :-)