December 31, 2018 at 8:35 pm
Comments posted to this topic are about the item The Next SQL Server Version
January 1, 2019 at 5:50 am
Today's Qotd leads to a secondary question, "What's new in SQL Server 2019?". There are fantastic things there will be enough to study. Thanks for this interesting question, Steve.
Happy New Year to all of you!
January 2, 2019 at 5:57 am
cheers for the question steve
---------------------------------------------------------------------------------------
The more you know, the more you know that you dont know
January 2, 2019 at 6:30 am
George Vobr - Tuesday, January 1, 2019 5:50 AMToday's Qotd leads to a secondary question, "What's new in SQL Server 2019?". There are fantastic things there will be enough to study. Thanks for this interesting question, Steve.
Happy New Year to all of you!
A search in Google for the very question you've quoted reveals the answer to that just a few posts from the top of the results.
https://docs.microsoft.com/en-us/sql/sql-server/what-s-new-in-sql-server-ver15?view=sqlallproducts-allversions
While I'm tickled that they've finally realized the concept of how scalar functions should actually work and that they've finally recognized the need for us to be able to handle UTF-8 files, I'm seriously disappointed in what they haven't done for things that have been complaints for a long time.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2019 at 7:24 am
Yes, they did at least something, but I want to start the new year in an optimistic mood ... 🙂
January 2, 2019 at 8:03 am
George Vobr - Tuesday, January 1, 2019 5:50 AMToday's Qotd leads to a secondary question, "What's new in SQL Server 2019?".
I'm most excited about the replacement of the notoriously inconvenient "string or binary data would be truncated" error with something more helpful.
And, the best part is it's getting backported to SQL 2016 and 2017!
January 2, 2019 at 8:04 am
Oh! … Briefly feared a trick question related to compatibility 'version' rather than 'level'.
January 2, 2019 at 8:41 am
George Vobr - Wednesday, January 2, 2019 7:24 AMYes, they did at least something, but I want to start the new year in an optimistic mood ... 🙂
Heh... that would be nice but the engine updates for SQL Server are sorely lacking in that regard.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2019 at 2:38 pm
Jeff Moden - Wednesday, January 2, 2019 8:41 AMGeorge Vobr - Wednesday, January 2, 2019 7:24 AMYes, they did at least something, but I want to start the new year in an optimistic mood ... 🙂Heh... that would be nice but the engine updates for SQL Server are sorely lacking in that regard.
I don't see it so skeptically. Perhaps MS will hear people's voice in other updates... :unsure:
January 2, 2019 at 7:44 pm
George Vobr - Wednesday, January 2, 2019 2:38 PMJeff Moden - Wednesday, January 2, 2019 8:41 AMGeorge Vobr - Wednesday, January 2, 2019 7:24 AMYes, they did at least something, but I want to start the new year in an optimistic mood ... 🙂Heh... that would be nice but the engine updates for SQL Server are sorely lacking in that regard.
I don't see it so skeptically. Perhaps MS will hear people's voice in other updates... :unsure:
Considering that they've kept things like the infamous request by Erland Sommarskog for a built in Tally-Table-Like function open for more than a decade but have done nothing about it but did have the time to come up with the rather stupid EOMonth function and considering that they've not added the critical currently missing functionality of String_Split() and have basically ignored all pleas to fix it since before it hit the streets and the fact that they'd release something SUM() OVER() and it took 7 years to respond to pleas to make that work, I'm not getting my hopes up. 😉
Don't get me started on the atrocities committed but never fixed when it comes to the likes of Recursive CTEs and the truly substandard PIVOT operator or the fact they've ignored the fact that Shrink File produces index inversion instead of being done in a Peter Norton fashion, that there's no reason why Index REBUILD should have to temporarily double the size of an index if it's over 8MB (128 extents) or why the supposedly low resource usage REORGANIZE blew out my log file from 20GB to 227B on a 146GB Clustered Index that only had 12% Logical fragmentation. How about the fact that the relatively "new" DATE and DATETIME2 functions still don't have the functionality that the ol' DATETIME datatype has and, instead of fixing it, came out with the (also stupid) DATEDIFF_BIG function to try to make up for it. And how about the wonderful functionality of a BULK_EXPORT and some file handling functions in T-SQL? Yeah.. not happening.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2019 at 7:05 am
Jeff Moden - Wednesday, January 2, 2019 7:44 PMConsidering that they've kept things like the infamous request by Erland Sommarskog for a built in Tally-Table-Like function open for more than a decade but have done nothing about it but did have the time to come up with the rather stupid EOMonth function and considering that they've not added the critical currently missing functionality of String_Split() and have basically ignored all pleas to fix it since before it hit the streets and the fact that they'd release something SUM() OVER() and it took 7 years to respond to pleas to make that work, I'm not getting my hopes up. 😉
Don't get me started on the atrocities committed but never fixed when it comes to the likes of Recursive CTEs and the truly substandard PIVOT operator or the fact they've ignored the fact that Shrink File produces index inversion instead of being done in a Peter Norton fashion, that there's no reason why Index REBUILD should have to temporarily double the size of an index if it's over 8MB (128 extents) or why the supposedly low resource usage REORGANIZE blew out my log file from 20GB to 227B on a 146GB Clustered Index that only had 12% Logical fragmentation. How about the fact that the relatively "new" DATE and DATETIME2 functions still don't have the functionality that the ol' DATETIME datatype has and, instead of fixing it, came out with the (also stupid) DATEDIFF_BIG function to try to make up for it. And how about the wonderful functionality of a BULK_EXPORT and some file handling functions in T-SQL? Yeah.. not happening.
Hmm ... there's something to think about. Thanks for this detailed information, Jeff.
January 3, 2019 at 3:35 pm
George Vobr - Thursday, January 3, 2019 7:05 AMHmm ... there's something to think about. Thanks for this detailed information, Jeff.
Heh... that's about 1/5th of my total list. 😀 Didn't want anyone to get bored and do a tldr: on it.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply