Connect digest : 2009-10-17
I've been fairly distracted this past week with my "Bad habits to kick" series, so apologies for being so late with the Connect digest. I stumbled upon a few pretty interesting items from the past two weeks; I hope you find them interesting as well.
It has bugged me that in order to show the original message in, say, a CATCH block, I have to assign ERROR_MESSAGE() to a variable first, since trying to call ERROR_MESSAGE() within RAISERROR() yields an error. I agree with this suggestion that we should be able to reference scalar functions within RAISERROR() (or some function that replaces RAISERROR() in the future).
A weird inconsistency in TRY / CATCH syntax means that you can place a statement terminator on BEGIN TRY, BEGIN CATCH, and END CATCH; however, if you add a semi-colon to END TRY, you get an error message. I am a big fan of using the semi-colon, and I knew there was a reason I don't bother doing so on my TRY / CATCH statements. I must have received this error early on and just assumed it wasn't "proper."
Now that we can have a true unique constraint that allows multiple NULL values (since a filtered index can be written such that NULLs are not included), Denny Cherry feels that we should be able to provide a foreign key reference to the values in the filtered index.
While my comment on this item indicates that there is a relatively easy workaround (just hit F4 and view the Properties pane), I do agree that it could be useful to have items like EndTime in the status bar of a query window. I think the display of these various things around the UI (SSMS status bar, query window status bar, tabs, title bar) should be a lot more flexible.
Jamie Thomson suggests that Management Studio have a built-in code formatter, along the lines of what we see in Visual Studio. As long as it is flexible enough to format code the way *I* like it, I agree. Yes, there are several 3rd party products that do a decent job of this, however I work on different machines on different days, in different physical locations, and often in several different VMs. Since these tools are licensed per client, it would be pretty expensive for me to license them on every instance of SSMS I use in a typical week.
Because Developer Edition supports all of the same features of Enterprise Edition, it is very easy to accidentally use a feature during development that you actually won't be able to use when you deploy, since production is some other edition (Standard, Workgroup, Web, Express). It would be really nice to get some kind of error or warning when you use a feature in Developer Edition that is not supported by the edition(s) you are planning to deploy to.