Big Data functionality!! Map reducing programs, schema on read functionality, combiners on the nodes, and some analytics on top of this would be fantastic! I need to combine our legacy information on SQL Server with our Big Data (currently NOT on SQL Server). We are doing sentiment analysis and predictive analytics. Very challenging at the moment.

In SSMS I'd like the delete and refresh buttons to not be right next to eachother. I'd like a confirmation in ssms before a db or table can be renamed when you slowly double click on the object in Object Explorer and fat finger the keyboard.

Yes! It's the one thing I miss the most from my Oracle days was being able to have a simple way to save stored procedure / view / function / etc scripts without having the awkward "if object doesn't exist, create a fake one" then ALTER it. Or worse, when someone writes a script with the DROP then CREATE methodology but doesn't include any GRANTs.

Something else I'd change would be to get rid of SET options at the object level like:ANSI_NULLSQUOTED_IDENTIFIERetc.

Regarding the signal:noise ratio at Connect, I wonder if that will change now that Microsoft has abandoned stack-ranking? I hope so. It seemed obvious Connect became a metric tied to some sort of rating.

Andy Leonard (1/31/2014)Regarding the signal:noise ratio at Connect, I wonder if that will change now that Microsoft has abandoned stack-ranking? I hope so. It seemed obvious Connect became a metric tied to some sort of rating.

Let me preface this rant by saying that you've hit a real "sweet spot" for me. I'll also say that I wouldn't trade in SQL Server for any other RDBMS but it could be SO much better. I'd actually like them to stop adding new features for a bit and spend some real quality time fixing all of the problems they've caused both by adding new stuff or fixing old stuff that has been wrong since I can remember.

For example, Why is it that they never fixed DBCC SHRINKFILE so that it works in more of a Peter Norton style where it would do some intelligent reorganization and optimization instead of having to rebuild every bloody index because the shrink code was done so incorrectly? Why is it the ALTER INDEX REORGANIZE doesn't do anything with the B-TREE? Why is it that ALTER INDEX REBUILD keeps a whole copy of the index for any table of 128 pages (only 8MB, BTW) instead of just keeping a copy of 1 or 2 pages at a time?

And then there's the subject of deprecation and removal of features. Query Analyzer had the {f4} key which very quickly allowed you to find an object by name in an entire server or database with the simple push of a button. SSMS has no such thing. And instead of being able to quickly and easily turn out hundreds of documents using sp_Makewebtask (which also allowed really simple style sheets) using a simple query, we now have to use the likes of SSIS, SSRS, resort to building HTML with idiotic tricks using for XML PATH, or (gasp!) resort to things like PoSH (which, at this point, I'm thinking is a very appropriate abbreviation ).

And then there's one of my pet peeves. Why do they think that I want to load the likes of SSIS just to import a true CSV file with quoted delimiters without having to go through and make an unsupported version of a BCP format file (BOL specifically states that CSV imports are not supported for BCP or BULK INSERT never mind \" for text qualifiers) or a simple spreadsheet without having to also load ACE drivers? Why is it that people have to go through all sorts of tricks just to get a decent directory listing using T-SQL? Why is it that BCP and BULK INSERT still won't allow you to skip column header "records" unless that "record" has precisely the same number, type, and order of delimiters instead of just skipping lines based on the end-of-line delimiter? And how about making it so that BULK INSERT can read from other machines based on simple sharing privs instead of having to setup trust between machines? BCP does it! Why not BULK INSERT???

How about that silly PIVOT function? Compare the functionality of that to PIVOT in Access and see how it really should work! Shoot, compare it against the ancient "black art" of writing a CROSS TAB and see which wins for performance!

Then, there are the ridiculous requirements surrounding both Partitioned Views and Partitioned Tables especially when it comes to FKs and that stupid PartitionScheme function. And the really big “winners” here are not being able to reassign a file to a different FileGroup and the fact that you have to set the whole database to “SINGLE_USER” just to make one silly little file used in a partitioned table READ-ONLY??? JEEZ!!!

And do you think they could make a decent BEFORE trigger to augment that nasty ol' INSTEAD OF trigger thing they've built? On no. Instead, they've wasted their time by deprecating being able to return anything from the trigger to SSMS using either SELECT or PRINT, which was one of the greatest troubleshooting tools there was for triggers.

Then, I see what they've done with Lead/Lag and the fact that a simple Quirky Update still blows the doors off of that functionality for running totals. Is it really that hard to write something that's actually an improvement?

Some decent file handling to support imports, exports, and backup file management would also be much appreciated. Is it so hard to write a BULK EXPORT? BCP does it!!!

And my biggest peeves of all... how about a built in Tally Table function that operates at machine language speeds or a decent built in split function? How long have those been on everyone's wish lists? There's actually a CONNECT item on the subject of the Tally/Numbers table/Function and it has been in an ACTIVE status for 7 bloody years! Is it THAT hard, Microsoft? You wrote CLRs to support HIERARCHYID! How hard is it to write a looping CLR that produces a sequence of numbers? Here’s the link for the Numbers Table CONNECT item.https://connect.microsoft.com/SQLServer/feedback/details/258733/add-a-built-in-table-of-numbers

I could go on with dozens of other peeves but, just like CONNECT, it appears to be a waste of time and effort.

We now return you to your regularly scheduled programming (pun intended).

--Jeff Moden"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T."--22 Aug 2013