February 3, 2017 at 9:18 am
Yep.
Ben
February 3, 2017 at 9:19 am
Interesting I changed the scope of the find to the Current block and it worked.
Kind of strange.
Thanks,
Ben
February 3, 2017 at 12:44 pm
Alex Gay - Friday, February 3, 2017 4:46 AMadelio.stevanato 21159 - Friday, February 3, 2017 4:26 AMAfter having used SSIS exclusively for over a year I vote for it to be scrapped and re-written.
the interface is inconsistent and buggy.
It crashes randomly
hard to get details of errors
and because it is all in one big XML file code merging and searching is impossible
it really feels like someone had a good idea and then half way through the development they got board and gave up!
ALL lists should be sortable, some screens you can sort by clicking on a column and others you cannot.
Just pooooor..... and very frustrating when you are trying to use it.I agree with you, SSIS is something I use because it is mandated not because I want to. I prefer to script everything, T-SQL or another scripting language, than use SSIS.
The niconsistencies need to be addressed, and not by removing features. There also needs to be an easy method to split large jobs into multiple files, as there is a file size limit and validation takes ages on large files.
There's an easy solution. Script everything in T-SQL, then call it with an Execute SQL task.
February 6, 2017 at 7:02 am
I wouldn't mind a better syntax for upsert. I mean, the current one is just lazy and stupid *for an upsert*. If the primary key is null, then it's an insert (and update the primary key parameter automatically), if it isn't, it's an update, if the insert fails because the key isn't in the table then insert it.
I suppose the existing merge is useful for actual complex merges but what about an upsert for simplicity's sake? Oh, I forgot. SQL Server doesn't do simple... 😛
(grumpy because I haven't had my caffeine yet)
February 6, 2017 at 7:38 am
roger.plowman - Monday, February 6, 2017 7:02 AMI wouldn't mind a better syntax for upsert. I mean, the current one is just lazy and stupid *for an upsert*. If the primary key is null, then it's an insert (and update the primary key parameter automatically), if it isn't, it's an update, if the insert fails because the key isn't in the table then insert it.I suppose the existing merge is useful for actual complex merges but what about an upsert for simplicity's sake? Oh, I forgot. SQL Server doesn't do simple... 😛
(grumpy because I haven't had my caffeine yet)
I'd just as soon they didn't. Look at how bad MERGE was for the first couple o' years. Then look at things like PIVOT, FORMAT, and some of the other "improvements" and tell me you'd trust an UPSERT command. I still don't trust MERGE simply because of all the data and performance problems they had with it.
--Jeff Moden
February 7, 2017 at 6:47 am
I'd like a GROUP BY AUTO function that groups by all the non aggregated fields to save me copying and pasting from my select and removing any aliases!! I use SQL prompt to do this for me but I'd prefer my code to be more terse and know that I can make a change to the select that is automatically added to the group by.
February 7, 2017 at 10:49 am
I saw a feature from Stream Analytics today that I would love to have in T-SQL
GROUP BY TransactionDate(Hour, 1)
Essentially group by one hour intervals of the TransactionDate. It can be done in T-SQL already, but it's cumbersome.
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
February 8, 2017 at 3:04 am
GilaMonster - Tuesday, February 7, 2017 10:49 AMI saw a feature from Stream Analytics today that I would love to have in T-SQLGROUP BY TransactionDate(Hour, 1)
Essentially group by one hour intervals of the TransactionDate. It can be done in T-SQL already, but it's cumbersome.
Hour intervals aren't too bad, it's when you want to start doing it in intervals of 2/3/4 etc that it gets "messy" I'd assume for 3 hour intervals the syntax would be GROUP BY TransactionDate(Hour, 3)? Where as to achieve that for T-SQL is something like GROUP BY DATEADD(HOUR, DATEDIFF(HOUR, 0, TransactionDate) - (DATEDIFF(HOUR, 0, TransactionDate) % 3),0). Certainly Stream is much cleaner, and easier to read for novices.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
February 8, 2017 at 3:19 am
Jeff Moden - Thursday, February 2, 2017 11:20 PMOne of the oldest and higher voted active connect requests (10 years on 2/18) that I see no glimmer of even being worked on can be found at the following CONNECT link. Of course, I'd like to see it materialize as a very high speed machine language function rather than a built in table.
https://connect.microsoft.com/SQLServer/feedback/details/258733/add-a-built-in-table-of-numbers
+ 1,000,000
That would be very useful.
Everytime I need a tally table, I need to look up the syntax again on how to create it (the so-called Ben-Gan style).
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
February 8, 2017 at 3:36 am
Thom A - Wednesday, February 8, 2017 3:04 AMGilaMonster - Tuesday, February 7, 2017 10:49 AMI saw a feature from Stream Analytics today that I would love to have in T-SQLGROUP BY TransactionDate(Hour, 1)
Essentially group by one hour intervals of the TransactionDate. It can be done in T-SQL already, but it's cumbersome.
Hour intervals aren't too bad, it's when you want to start doing it in intervals of 2/3/4 etc that it gets "messy" I'd assume for 3 hour intervals the syntax would be GROUP BY TransactionDate(Hour, 3)? Where as to achieve that for T-SQL is something like GROUP BY DATEADD(HOUR, DATEDIFF(HOUR, 0, TransactionDate) - (DATEDIFF(HOUR, 0, TransactionDate) % 3),0). Certainly Stream is much cleaner, and easier to read for novices.
The SQL standard allows for an interval data type (which is not implemented in SQL Server). That would be useful as well.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
February 8, 2017 at 4:57 am
Thom A - Wednesday, February 8, 2017 3:04 AMI'd assume for 3 hour intervals the syntax would be GROUP BY TransactionDate(Hour, 3)?
Precisely.
I had a 'group into 5 minute intervals' requirement a couple years back, and that was just painful.
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
February 8, 2017 at 6:35 am
GilaMonster - Wednesday, February 8, 2017 4:57 AMThom A - Wednesday, February 8, 2017 3:04 AMI'd assume for 3 hour intervals the syntax would be GROUP BY TransactionDate(Hour, 3)?Precisely.
I had a 'group into 5 minute intervals' requirement a couple years back, and that was just painful.
Painful for you or the optimizer to group by DATEADD( mi, DATEDIFF( mi, '2016', n)/5*5, '2016') ?
February 8, 2017 at 7:25 am
Luis Cazares - Wednesday, February 8, 2017 6:35 AMGilaMonster - Wednesday, February 8, 2017 4:57 AMThom A - Wednesday, February 8, 2017 3:04 AMI'd assume for 3 hour intervals the syntax would be GROUP BY TransactionDate(Hour, 3)?Precisely.
I had a 'group into 5 minute intervals' requirement a couple years back, and that was just painful.
Painful for you or the optimizer to group by DATEADD( mi, DATEDIFF( mi, '2016', n)/5*5, '2016') ?
Me to write, complete with the arithmetic overflow on the first attempt
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
May 7, 2017 at 3:00 pm
I'd like to see SQL Server get rid of nonsense like the sum of an empty set being NULL instead of 0, but of course we would need to get the SQL standard corrected before any supplier could afford to make that change, and if JC's attitude to it is typical of people on the standards committee those people are either too stupid or too pig-headed (or perhaps both) to get that right.
Tom
May 7, 2017 at 3:31 pm
Jeff Moden - Friday, February 3, 2017 1:01 AMThat's just the top feature. What I'd really like is (to name a few)...
1. Make the ACE drivers more intelligent and useful.
2. Make FORMAT run at least as fast as Cast/Convert.
3. Make it so the DATE/DAETIME2 datatypes can use direct math like DATETIME can.
4. Make the error outputs to file for BULK INSERT as easy to read as the errors on the screen.
5. Make BULK INSERT a bit more flexible for privs.
6. Make a BULK EXPORT.
7. Make it so that xp_CmdShell logs who's using it for what.
8. Make is so that if you have to stop a proc that uses xp_CmdShell, that it will also kill that instance of Cmd.exe so that you don't have to do it manually through task manager.
9. Make a decent DIR command available for T-SQL along with some file handling.
10. Stop deprecating and discontinuing useful stuff like the old sp_MakeWebTask.
11. Make it so that XML will "self flatten" into a table without having to know any of the column names.
12. Stop deprecating and discontinuing useful stuff like the old {f4} key functionality that was available in 2000 EM..
13. Make PIVOT work at least as well as what it does in ACCESS.
14. Make it so that string truncation warnings tell you the row number and column name where the truncation took place.
15. "Peter Nortonize" index maintenance and database "shrinks".
16. Fix partitioned tables. They're seriously broken in several aspects.
17. Fix partitioned views. They're seriously broken in several aspects.
18. Make the equivalent of sys.SQL_Modules for tables.
19. Add a column to system "what's running" tables to identify which statistics where used to create cached queries.
20. Stop deprecating useful stuff.
21. Fix decimal and floating point math. It's broken. Especially the automatic rounding stuff. Computers have these new fangled things called "math coprocessors", ya know?
22. Stop deprecating useful stuff.
23. Make it so when new features are introduced, they are complete and perform well.
24. Make it so that things like OPENROWSET, OPENQUERY, OPENDATASOURCE, BULK INSERT, database settings (like sizes and growth) scripts and the FROM clause in queries, etc, etc, can take variables instead of have to go through dynamic SQL.
25. Finish writing the bloody new splitter function so that it returns the element positions. (see 23 above).
26. Make it so you can point at a file and it'll make both the target table and the BCP Format file for you.There's more but I figure that's probably 26 years of work for them. They'll never get to the other stuff I'd like to see because they won't get to most of anything in the list above. 😉
Have I mentioned that I'd like them to stop deprecating and discontinuing useful stuff? 😉
I like all of those; I guess I would have a different priority order: 1,4,7,8,14,21,10,12,20,22,23 and then the rest in the order you've put them. Number 21 should ideally include support for the latest floating point standard so that we could scale the mantissa/significand (why don't we have just one word for the thing) by a power of 10 instead of by a power of 2, thus eliminating all the irritation and problems caused by not being able to represent the same numbers that we represent in printed form - no more representation problem.
Tom
Viewing 15 posts - 31 through 45 (of 56 total)
You must be logged in to reply to this topic. Login to reply