June 28, 2016 at 11:37 pm
If I release v1.2 and I break some feature or cause a performance issue, then that's bad.
Steve, that there is my problem with Microsoft. If I develop an application and everything goes well but I have a few bugs to fix and now I break a feature, how can I then release my application and expect users to be happy. I need to test my work first before releasing, isn't it? With MS though I have to wait months for a new release and meanwhile my users are giving me hell because the feature MS broke is used in an application my users use. Sorry, but that is unacceptable.
Manie Verster
Developer
Johannesburg
South Africa
I am happy because I choose to be happy.
I just love my job!!!
June 29, 2016 at 3:39 am
Steve Jones - SSC Editor (6/28/2016)
...I think you're conflating things here, Gary...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...
My point is against the assertions that the quality of releases has improved. I was just trying to point out that you need to consider ALL releases to decide whether there has been an improvement in the quality of releases. I certainly expect defects as I, like most if not all of us, understand the compromises that we all have to make when developing and releasing software. Also, I certainly expect that current releases give us more than previous releases (in general).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 29, 2016 at 4:54 am
Jeff Moden (6/28/2016)
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"
Where specifically? The only comment I can see in that section that refers to something broken is the CE changes to 2014 which changed the plan and resulted in non-random data.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 29, 2016 at 11:31 am
GilaMonster (6/29/2016)
Jeff Moden (6/28/2016)
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"
Where specifically? The only comment I can see in that section that refers to something broken is the CE changes to 2014 which changed the plan and resulted in non-random data.
The code block immediately above that comment. If you run it in 2012 or less, works as expected. According to Wayne, if you run it in 2014 or better, it still runs but not as expected. Instead of making unique rows, it makes identical rows (which I lovingly refer to as "grooved data").
--Jeff Moden
Change is inevitable... Change for the better is not.
June 29, 2016 at 12:44 pm
manie (6/28/2016)
If I release v1.2 and I break some feature or cause a performance issue, then that's bad.
Steve, that there is my problem with Microsoft. If I develop an application and everything goes well but I have a few bugs to fix and now I break a feature, how can I then release my application and expect users to be happy. I need to test my work first before releasing, isn't it? With MS though I have to wait months for a new release and meanwhile my users are giving me hell because the feature MS broke is used in an application my users use. Sorry, but that is unacceptable.
So, this is software. Things can break across releases, which is why depending on someone else is tough.
If you've developer for SQL 2016, then you should be aware of what works. If you built on SQL 2014 (2012, whatever), will 2016 break you? Maybe, but you'd have to test. Microsoft goes to a lot of effort to avoid breaking old code. Too much, in my opinion, which holds back the platform.
I'm not sure I understand what your complaint is with Microsoft and having to wait. Patches take time, they come in Azure quicker, but they still can take months. If a change in 2016 breaks your feature, don't upgrade. That's fine. In no way am I saying everyone should upgrade or install this. Just that it's a good release.
If you expect MS to release software the doesn't break any of your old code, AND doesn't break my old code, AND doesn't break Gail's old code, AND everyone else's old code, I think you're being unreasonable.
June 29, 2016 at 12:49 pm
Jeff Moden (6/29/2016)
GilaMonster (6/29/2016)
Jeff Moden (6/28/2016)
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"
Where specifically? The only comment I can see in that section that refers to something broken is the CE changes to 2014 which changed the plan and resulted in non-random data.
The code block immediately above that comment. If you run it in 2012 or less, works as expected. According to Wayne, if you run it in 2014 or better, it still runs but not as expected. Instead of making unique rows, it makes identical rows (which I lovingly refer to as "grooved data").
OK, but I'm not sure that broke a whole lot of code. Certainly could be a regression, but there's a workaround. This also is a 2014 break, or did you note that earlier? This isn't a SQL 2016 issue, and not sure it's more than a change in behavior rather than something not working.
June 29, 2016 at 2:02 pm
Jeff Moden (6/29/2016)
According to Wayne, if you run it in 2014 or better, it still runs but not as expected. Instead of making unique rows, it makes identical rows (which I lovingly refer to as "grooved data").
But that's not something that SQL 2016 broke, you said "this release broke..." Hence Grant (probably) and I have been hunting for XML concat problems reported in 2016 and coming up blank.
The CE rework changed a lot of things, not really surprising when re-writing a hell of a complex part of the QO that's been in use for ~20 years. It's why I insist on detailed upgrade tests from 2012 or before to 2014 or later.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 29, 2016 at 11:48 pm
If you expect MS to release software the doesn't break any of your old code, AND doesn't break my old code, AND doesn't break Gail's old code, AND everyone else's old code, I think you're being unreasonable.
If it broke my code I could live with it, but this is a feature (Database Mail) in SQL Server that was broken and I used the feature for automated e-mails to be sent. Thing is, the users do not understand that MS broke their own feature but see me as the developer and I need to fix it. If it broke my code I could probably fix my code and accept it as that and move on with my life. Concerning about not upgrading, I would not have upgraded if I knew this would happen but these things only pop out after you upgraded.
Manie Verster
Developer
Johannesburg
South Africa
I am happy because I choose to be happy.
I just love my job!!!
June 30, 2016 at 1:17 am
But surely you picked the DB Mail problem up in your pre-upgrade testing?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 30, 2016 at 1:37 am
When SQL Server 2005 was released, there was an upgrade to ADO. The previous version of ADO had a particular call structure (I forget the precise details, it has been eleven years) that was changed with the new ADO. Functionally, everything in SQL Server was exactly the same or better, but one of our apps was broken by the upgrade (and yes, we determined this in testing, prior to going to production with the change).
This is not the kind of bad release I'm trying to talk about. Instead, think of the service packs that get released, and then immediately recalled because they're fundamentally broken. A change to SQL Server that breaks your code is not the same thing as SQL Server itself being broken. Fundamentally these are different. My argument is simply that SQL Server seems to be broken much less often on release than it used to be and I attribute this to the fact that Microsoft, as an organization, is getting lots more practice at releasing functional code because they now do it so often.
All these arguments that an internal change, but still functional, in SQL Server causes problems with down stream systems are besides the point of the editorial. These really are two separate issues, you must see. Functional, although changed, code versus non-functional code.
"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
June 30, 2016 at 5:46 am
GilaMonster (6/30/2016)
But surely you picked the DB Mail problem up in your pre-upgrade testing?
No, I am afraid you have me. I did not test it as I am sure nobody can sit and test each and every feature in SQL. My point is this. When I release an upgrade of my software I make sure I have tested it thoroughly and that no features are broken that used to work. When my clients upgrade they might still have a few bugs and I fix that. If it so happens that I broke a feature I don't let them wait for months before I fix it. I get it done as soon as possible. Over and out.
Manie Verster
Developer
Johannesburg
South Africa
I am happy because I choose to be happy.
I just love my job!!!
June 30, 2016 at 6:24 am
manie (6/30/2016)
GilaMonster (6/30/2016)
But surely you picked the DB Mail problem up in your pre-upgrade testing?No, I am afraid you have me. I did not test it as I am sure nobody can sit and test each and every feature in SQL.
No, and that's not what I suggested. Testing your application against the new version before updating production, now that can be done.
If it so happens that I broke a feature I don't let them wait for months before I fix it. I get it done as soon as possible. Over and out.
http://www.sqlservercentral.com/Forums/Topic1796418-3739-1.aspx
Edit: And if that doesn't help, see https://support.microsoft.com/en-us/kb/3135244, under the section Known Issues, see Issue 7
Issue 7
Database Mail does not work with TLS 1.2. Database Mail fails with the following errors:
Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException:
Mail configuration information could not be read from the database.
….
….Unable to start mail session.
For additional information refer to the section titled Additional fixes needed for SQL Server to use TLS 1.2 in this article.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 12 posts - 16 through 26 (of 26 total)
You must be logged in to reply to this topic. Login to reply