November CTP : Initial impressions of SSMS changes
[Updates below in BOLD.]
On loading SSMS for the first time, I noticed a few things. First of all, the row(s) affected message is now prefixed with information on the instance and login relevant to the query execution. This information is already available in the status bar. Why are they spoon-feeding it to us in the row(s) affected message?
Next, I noticed the region-like behavior that has been added. You cannot define your own regions, but the more typical code blocks you would want to hide/show are supported by default. (Except block comments.)
Error highlighting is not all that perfect just yet. Sure, it identifies common syntax errors and undeclared variables, but it also yields a false positive on perfectly valid function names, such as OBJECT_SCHEMA_NAME(). [Note from Connect #311086 : this will be fixed.] Notice also that syntax highlighting has taken a step backward. sys.objects, for example, should be green; OBJECT_SCHEMA_NAME and OBJECT_ID should be pink. [Note from Connect #311089 : this will be fixed.]
And finally, I got to play with the much-anticipated IntelliSense functionality. I already knew that it was not supported for many syntax operators (primarily SELECT). It was pretty fast in my tests against a local instance, however I have not played with it yet remotely (performance here is the main reason I can't use Red-Gate's product). I was disappointed to discover that in a query with a single table/view, if you do not use an alias, the auto-complete list includes everything under the sun, making it very cumbersome to find and select valid column names. [Note from Connect #311088 : they are trying to make this better, including sorting in CTP6.] If you use an alias, however, this allows you to narrow down your list considerably. Not the most intuitive thing in the world, but I guess I will learn.
And Dave, I am not saying your suggestion for color-coding is invalid (in fact, I voted for it on Connect, if you were the one who posted that suggestion). But I don't think this printout helps in the same way that such color-coding would.
Dave, what information is added to this print out that isn't already available in the status bar for the current query window?
(Again, in the case where you are running queries against a SQL Server.)
Yes Paul, but that feature should only be turned on if you are actually executing a query against multiple servers. If you are only running against a single server, it is in the way (and redundant). They mentioned in a Connect item that they are going to fix it.
another reason for listing the connection info in the messages, is that you can now submit T-QL to groups of server with a single Execute.
I have a reason for the first change and it partial address an issue I brought up with the SQL Recommendation group (forgot the correct name of the group) dealing with making it a bit more delineated as to which database instance you are working in. I am not alone in having development servers set up as a mirror of the production side so picture this; while having both instances open in object explorer you believe that you are testing a change on the developer side, easy enough to do when you have many databases per instance and the instance identification gets buried at the top and you are scrolled down to the middle, only to actually push the change into production by mistake. At least with the instance name displayed you have a more immediate chance to correct a problem before being notified by users.
My actual request was that they add a user selectable background color for each instance in the object explorer to help prevent the situation described above.
Cool feature… Copied from LINQ?? 😉