Why SQL Server Users Commonly Hate Connect

SQL Server isn’t cheap. Licensing costs alone for a simple 4-core VM running SQL Server Standard Edition (and the Software Assurance required to make those licenses worthwhile) will typically cost around $10,000 to license for 2 years – while Enterprise Edition Licenses for the same VM would weigh in at closer to $40,000 for those same two years.

Against such a backdrop, when users post detailed information about bugs, problems, or issues – only to have their reports dismissed with “Closed – as Won’t Fix”, it’s not hard to see why so many SQL Server users end up hating connect. To them, Connect is (at worst) either an affront to the amount of money they’ve invested in SQL Server as a product or (at best) simply a quagmire: a place where bug reports and feedback enters only to become aimlessly lost, overlooked for years to come,  and possibly never see the light of day again.

And, I get it: In order for SQL Server to remain competitive, Microsoft has to keep their limited pool of developers (there’s a real talent shortage in terms of the skill-sets needed to work on something as complex as SQL Server’s internals) focused on tight deadlines if new features and and capabilities are ever going to ship – meaning that Microsoft sometimes has to take a hard-line when it comes to bona-fide bugs.

But, ultimately, there’s still a perception that Microsoft simply doesn’t care or can’t be bothered – in far too many cases.

One Thing Microsoft Could and Should Do to Help with this Problem

One thing Microsoft really needs to do, is go BACK and re-evaluate previously closed bug reports.

For example, consider this report – covering a problem with reviewing data from Extended Event Sessions. Originally filed against SQL Server 2014, the issues was closed as not reproducible. Fair enough – sometimes trying to reproduce bugs is hideously difficult – especially when there might not be enough detail or context in the first ‘repro’ sent in with a given bug. But, all these years later, the bug still exists (even against SQL Server 2016) and the bug continues to be “Closed” or ignored – whereas there IS a simple explanation for what’s going on and IF Microsoft were to review closed bugs, you’d assume they’d re-evaluate this one, see what’s going on, and FIX the problem.


No responses yet

Leave a Reply