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.

#498082 : Allow direct usage of scalar functions in RAISERROR()

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).

#498085 : END TRY throws an error if terminated with a semicolon

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."

#498009 : Allow filtered unique index to be a candidate key for a foreign key

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.

#497345 : SSMS add Query EndTime next to Execution Duration in the Query Window

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.

#496617 : "Format Document" in SSMS

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.

#496380 : Enable SQL Developer Edition to target specific SQL version

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.