T-SQL Tuesday #86: My Favorite Connect Items
This month's T-SQL Tuesday topic is "SQL Server Bugs & Enhancement Requests." This is a topic near and dear to my heart; for several years I was a huge proponent of the Connect system. For a while, I even published weekly digests, where I highlighted bugs and feature requests that I thought deserved more eyeballs and votes. (A few people didn't like that - accusing me of giving preferential treatment and more visibility to issues I cared about. Yeah, that was kind of the point.)
I am still a firm believer in the improvement site, though I expend a lot less effort on it these days. Not because it doesn't work, but because the various teams have a less unified experience - some use various combinations of Trello, UserVoice, and Yammer, while only a few teams still seem to be using Connect.
For this month's T-SQL Tuesday, Brent Ozar (@BrentO) asked us to write about our favorite Connect bug or enhancement request. I'm going to do him one better, and talk about two different Connect items:
- My favorite unresolved Connect item
- My favorite resolved Connect item
I want to talk about both because, while I think it can be useful to promote important issues that haven't been addressed, I think it's also important to reinforce that Connect items do get considered by the team, and sometimes get fixed. There was certainly a period where it may have felt like all that work was going to
/dev/null/, but I can assure you that's not the case today.
My favorite unresolved suggestion
There are so many active Connect items, it's difficult to choose just one, but after spending some time looking at the
generate_series function in PostgreSQL, the one at the top of my list right now is this suggestion from Erland Sommarskog (blog):
I think it would be cheap and easy for SQL Server to provide a defaut table of numbers, always in memory, just like any other catalog view or DMV. This thing can use compression now, regardless of edition, so even a table with 2 billion rows will not take a crazy amount of space, and should be easy to populate either at start-up or on first use. I could list out all of the potential uses for a numbers table, but they're fairly well documented in the following sources (and most use cases don't need anywhere near 2 billion values, so maybe the range could be defined using a
sys.configurations or database-level
SCOPED CONFIGURATION setting):
Well, I can't just talk about one unresolved bug or suggestion, can I? There are several others I'd love to see addressed. In no particular order, here are a few:
My favorite resolved suggestion
Without a doubt, my favorite fix has been a recent one, and that is the addition of
CREATE OR ALTER in SQL Server 2016 SP1. This gives us the ability to make changes to modules like views, functions, triggers, and stored procedures, without having to resort to dynamic SQL or other convoluted logic just to determine if the object already exists. I've seen many deployments go south because this logic is complicated and very easy to mess up.
There's not much else to say about this really, except job well done by the SQL Server team; they've listened and implemented something we've been asking for, for literally years. Here are the related Connect items, though not all are marked as resolved:
(The original item, 127219, has disappeared, but the wayback machine has it, in all its unformatted, barely legible, Times New Roman glory!)
One thing to keep in mind: Denis Gobo discovered that the logic is broken for DDL triggers (see Connect #3111866 - I'm sure this will get addressed in short order).
I was quite happy to see two of my recent suggestions make it into the product last year:
- #2374513 : Add CREATE DATABASE AS COPY OF syntax - this was implemented via
DBCC CLONEDATABASE, which have been blogged about by Melissa Connors here and Erin Stellato here.
- #2088233 : Add parameter data types to showplan - they didn't implement this exactly as I suggested, but some execution plans now contain more valuable info about parameters (see KB #3190761).
Aaron (@AaronBertrand) is a Product Manager at SentryOne, with industry experience dating back to Classic ASP and SQL Server 6.5. He is editor-in-chief of the performance-related blog, SQLPerformance.com, and serves as a community moderator for the Database Administrators Stack Exchange. Aaron's blog focuses on T-SQL bad habits and best practices, as well as coverage of updates and new features in Plan Explorer, SentryOne, and SQL Server.