Connect Digest : 2009-10-02
Welcome to October! This week I have five SQL Server items to point out to you, and two Connect-specific issues.
Greg Linwood has been pushing for several items in the area of separating index data from actual data. One such idea is to allow backup / restore without index data (though I don't necessarily agree that one of the top reasons for implementing this would be for saving energy :-)).
This is Erland's suggestion, much in line with Greg's above, where you could indicate that a filegroup only contains index data. If implemented correctly, this would allow you to backup / restore the filegroup without requiring that you bring the index data along with it.
I'm bitten by this issue every once in a while. On a very busy clustered instance, with uptime in the months or more, loading the most recent SQL Server log through the UI can be very cumbersome indeed. Especially when you know the event you after happened today. I'd like to see a set of filter criteria *before* the load starts.
It is funny that members of the db_owner role can do pretty much anything they want in the database, except update statistics. It would seem that the update statistics code checks to see if the caller is actually *the* owner of the database (e.g. the owner_sid column in sys.databases) as opposed to just checking if they are in the db_owner or sysadmin roles.
Another issue spotted by Erland; when you use SSMS in results to text mode, displaying data from DATETIME2(3-7) results in a truncated display (as if you used DATETIME or DATETIME2(2)). Obviously we shouldn't see a difference in output depending on whether you use text or grid, especially when there are no carriage returns or line feeds involved.
I filed this issue when I used Connect for the first time after their changes this past weekend (which I talked about here). Sadly, on the SQL Server connection, there is a big orange "submit feedback" button in the middle of the screen, which used to work, but now doesn't. If the button doesn't do anything (the reason is that search is required before actually submitting), then it should be removed. The page is now a mess, IMHO.
Erland makes a pretty good case demonstrating that the updates this past weekend broke the search functionality, at least on the SQL Server connection. Now if you enter a series of keywords to search on, it actually searches for exact phrase. This is not very good because you either have to make your search criteria too broad (and have to step through too many results manually) or miss results because it was too narrow.