SQL Server 2016 is Out and It's Fabulous!

  • Comments posted to this topic are about the item SQL Server 2016 is Out and It's Fabulous!

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • From the Article:


    “This doesn’t work like it used to.”

    While I agree that it probably has fewer bugs that previous releases, this one broke a whole lot of code where people used XML for purposes of concatenation according to some.

    --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.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • You know I don't argue with you. I haven't seen this. Do you have an example, just to educate me.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • I have been searching the web for pros and cons for SQL 2016 but only get positive stuff. No and I repeat no new software goes without bugs. I know because I am a developer myself.

    When SQL 2012 came out our company bought it without first checking or anything and all of a sudden DB Mail is not working as it should. I had an expert look at it for me and eventually we came on a post where somebody complained about this same thing. Microsoft answered: "Oh sorry we know about that thing. Please wait till the next service pack comes out." Just like that.

    Please excuse me if I am not over exited about this new software. I skipped 2014 and maybe I can skip this one as well, I don't know. :crazy::crazy::crazy::crazy::crazy::crazy::crazy::crazy:

    Manie Verster
    Developer
    Johannesburg
    South Africa

    I am happy because I choose to be happy.
    I just love my job!!!

  • I absolutely hear you. I've been working with 2016 for quite some time now. I just haven't hit major issues. Not like with other releases. I'm not about to argue that it's perfect. No such thing. I do think it's actually a superior software release.

    Jeff points out above, there seems to be something up with XML. I recently hit a small bug with the Query Store (I couldn't cast the plan there as XML, although it seemed to be a valid plan since I could force its use on to the optimizer). I'm not arguing perfect here, just better.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Grant Fritchey (6/27/2016)


    I absolutely hear you. I've been working with 2016 for quite some time now. I just haven't hit major issues. Not like with other releases. I'm not about to argue that it's perfect. No such thing. I do think it's actually a superior software release.

    Jeff points out above, there seems to be something up with XML. I recently hit a small bug with the Query Store (I couldn't cast the plan there as XML, although it seemed to be a valid plan since I could force its use on to the optimizer). I'm not arguing perfect here, just better.

    Grant, I actually read some good things about this release. It just cheeses me off when Microsoft takes such a laidback attitude to the problems we have on their software and you, the developer, has to listen to the unhappy users. I, although I don't like to admit it, are quite excited about some new features in 2016. Just giving it some time to see what bugs pop out.

    Manie Verster
    Developer
    Johannesburg
    South Africa

    I am happy because I choose to be happy.
    I just love my job!!!

  • Surely it can only be considered an improvement in releases if the original SQL Azure releases went better than before?

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Gary Varga (6/28/2016)


    Surely it can only be considered an improvement in releases if the original SQL Azure releases went better than before?

    Gary, I would sincerely hope it is an improvement. Why else would they bring out new releases? It's just that sometimes something falls out.

    Manie Verster
    Developer
    Johannesburg
    South Africa

    I am happy because I choose to be happy.
    I just love my job!!!

  • manie (6/28/2016)


    Gary Varga (6/28/2016)


    Surely it can only be considered an improvement in releases if the original SQL Azure releases went better than before?

    Gary, I would sincerely hope it is an improvement. Why else would they bring out new releases? It's just that sometimes something falls out.

    Fair point but I meant it could only be considered an improvement in the quality of releases that Microsoft makes if the original SQL Azure releases went better than before i.e. if it is a better release just because all the rubbish releases were SQL Azure releases then there is no real improvement just the perception of improvement.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • OK, you'll have to explain that to me better. If Azure releases are bad, that makes the SQL Server release better? I don't get that.

    Microsoft is releasing SQL Server more often than once every two years. They're doing releases, into production, every two weeks (or there abouts, I think there is some variation), in Azure. Every so often, one of these does go wonky, but by and large they're quite successful. My argument is, all this practice is paying off. Instead of releasing once in two years, and screwing it up, releasing constantly is making them better, even at the big release of the core SQL Server product.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Grant Fritchey (6/28/2016)


    OK, you'll have to explain that to me better. If Azure releases are bad, that makes the SQL Server release better? I don't get that.

    Microsoft is releasing SQL Server more often than once every two years. They're doing releases, into production, every two weeks (or there abouts, I think there is some variation), in Azure. Every so often, one of these does go wonky, but by and large they're quite successful. My argument is, all this practice is paying off. Instead of releasing once in two years, and screwing it up, releasing constantly is making them better, even at the big release of the core SQL Server product.

    I am not suggesting there is not improvement. I am just saying that if in year 1 there is a SQL Server release which goes well and then in year 3 there is another release and it goes well that in of itself does not say that the dozen SQL Azure rollouts in between have necessarily improved the quality of releases from Microsoft's SQL team. If the impact of all/most of the SQL Azure releases we also pain free and caused minimum negative impact then, yes, there has been an improvement. Otherwise there may have not been.

    Any clearer? I am not sure that I am making the point very well.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Gary Varga (6/28/2016)


    Grant Fritchey (6/28/2016)


    OK, you'll have to explain that to me better. If Azure releases are bad, that makes the SQL Server release better? I don't get that.

    Microsoft is releasing SQL Server more often than once every two years. They're doing releases, into production, every two weeks (or there abouts, I think there is some variation), in Azure. Every so often, one of these does go wonky, but by and large they're quite successful. My argument is, all this practice is paying off. Instead of releasing once in two years, and screwing it up, releasing constantly is making them better, even at the big release of the core SQL Server product.

    I am not suggesting there is not improvement. I am just saying that if in year 1 there is a SQL Server release which goes well and then in year 3 there is another release and it goes well that in of itself does not say that the dozen SQL Azure rollouts in between have necessarily improved the quality of releases from Microsoft's SQL team. If the impact of all/most of the SQL Azure releases we also pain free and caused minimum negative impact then, yes, there has been an improvement. Otherwise there may have not been.

    Any clearer? I am not sure that I am making the point very well.

    Well then, I'm back to where I was.

    Yeah, the releases seem to be better and better and I'm attributing that to the practice that they're getting from Azure, because those releases are (by and large, there are always exceptions) very successful.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Gary Varga (6/28/2016)


    I am not suggesting there is not improvement. I am just saying that if in year 1 there is a SQL Server release which goes well and then in year 3 there is another release and it goes well that in of itself does not say that the dozen SQL Azure rollouts in between have necessarily improved the quality of releases from Microsoft's SQL team. If the impact of all/most of the SQL Azure releases we also pain free and caused minimum negative impact then, yes, there has been an improvement. Otherwise there may have not been.

    Any clearer? I am not sure that I am making the point very well.

    I think you're conflating things here, Gary.

    If I release v1 and it's great, that has some quality bar.

    If I release v1.1 and things work, we're happy.

    If I release v1.2 and I break some feature or cause a performance issue, then that's bad.

    I release v1.3, fixing things in v1.2.

    I release v1.4, adding a great feature, but breaking something else.

    I release v1.5, adding performance improvements and fixing v1.4.

    You upgrade to v1.5. Did we have quality improvement? It probably depends, but if you didn't encounter issues in v1.2 and v1.4, then I think you'd see this as a quality improvement and better releases.

    You're a developer. You break things at times. Does that not mean that quality doesn't increase? I hope so, and I'm sure you hope clients think so as well.

    That's the nature of building and enhancing something. Whether that's software, a building, a car, a product, whatever. Sometimes our improvements cause issues, and need to be fixed. That doesn't mean we don't learn and produce better work.

    I think SQL 2016 is a vast improvement, but it is perfect? No. Certainly there are bugs in there, and there will continue to be. However, there is also a larger focus on quality and measurement of the work. Releasing into Azure probably happens every day from developers, but the MSSQLServerTeam_Azure != AzureSQL that you and I buy. They test things, let beta users, internal customers, etc use things. They gather metrics, eventually put some things in private preview, some public preview, then some GA. Some of those will get to the on premise product. Eventually I think most things that get to public preview (and GA) get to the on premise product.

    Like us, they write code that doesn't work. However they continue to measure and improve things.

    I think SQL 2008 was a good release (2005 was, but more buggy). 2008 R2, 2014 were barely full releases to me. I'm torn on 2012, but certainly 2016 is a good release. Lots of additions, lots of improved functions. A few things broken, but few, and probably not many that impacted large groups of people.

    As always, YMMV, but I think if you can take advantage of features, or need to maintain support, this is a good release to run for a long time.

  • Jeff Moden (6/25/2016)


    From the Article:


    “This doesn’t work like it used to.”

    While I agree that it probably has fewer bugs that previous releases, this one broke a whole lot of code where people used XML for purposes of concatenation according to some.

    You'll have to provide a reference. I haven't seen this at all, nor can I find anything in searches. Perhaps I'm not looking in the right places, but I'd like to see a repro before I believe this.

  • Steve Jones - SSC Editor (6/28/2016)


    Jeff Moden (6/25/2016)


    From the Article:


    “This doesn’t work like it used to.”

    While I agree that it probably has fewer bugs that previous releases, this one broke a whole lot of code where people used XML for purposes of concatenation according to some.

    You'll have to provide a reference. I haven't seen this at all, nor can I find anything in searches. Perhaps I'm not looking in the right places, but I'd like to see a repro before I believe this.

    http://www.sqlservercentral.com/articles/STRING_SPLIT/139338/

    See the section under "Creating Large Scale Test Data"

    --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.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 15 posts - 1 through 15 (of 26 total)

You must be logged in to reply to this topic. Login to reply