AdminMicrosoft SQL Server
(Admin, Microsoft Azure)
My feedback
-
9 votes
I could add this functionality fairly quickly if I limit it to writing the executed query and some metadata about the results just to the Output window. Then the user could at least scroll through the Output window to find old queries to run etc. We would avoid any issues related to password persistence on disk etc.
Some questions about that approach:
1. Does it solve the most common issues that generate this request, albeit with not many bells and whistles?
2. We probably need to cap the length of text we save for any one query, I know some people have huge SQL files they execute. What’s a good “max size” that’s still generally useful?
3. I would optimize this feature for adhoc queries not for remembering big queries loaded straight from a file. Would it be ok to limit the recorded queries to just those from unnamed query… -
3 votes
maybe this item becomes combined with this one: https://feedback.azure.com/admin/v3/suggestions/33532654/activity
-
28 votes
Expect dramatic improvement in the new few months.
we've made changes to the "bad query" in recent versions of SMO to improve the worst case time. Previous versions where joining on DMVs like db_hasaccess and such that really slowed things down. Do you see any improvement in recent SMO NuGet package versions?
-
0 votes
When you close a query window SSMS tries to ping the server to see if the connection has any open transactions. Depending on your connection string and the version of the .Net framework installed, the version of SQL connected to, etc, making that connection active after a long idle period can take some time.
-
531 votes
Upvotes: 1
Thank you all for the feedback, we are actively looking at addressing this.
After all these years, the message
Msg 8152, Level 16, State 6, Procedure <ProcName>, Line 61
String or binary data would be truncated.is a little outdated. PLEASE tell us the name of the column that is too short to hold the data. We can figure it out, eventually, but it is often tedious. The system knows the answer, so it should tell us.
This would greatly simplify developers' lives. While you're at it, why not say whether it's STRING data or BINARY data?
This reminds me of a hypothetical error message that says "There's an error somewhere, but we're not going to tell you where it is. You have to find it yourself."
All information that the system has, which can be given to the programmer, should be given.
AdminMicrosoft SQL Server
(Admin, Microsoft Azure)
shared this idea
·
-
2 votes
Do you mean some other settings than what are included in Tools/Options/Query Results/Sql Server/Results to Grid ?
-
11 votes
We’ll investigate for a future release.
I've moved it to the "SQL Server" forum, where this can discovered more easily by us (SSMS feature Team).
-
0 votes
Upvotes: 0
Thank you for the suggestion. Vulnerability Assessment can now be run using SSMS 17.4.
AdminMicrosoft SQL Server
(Admin, Microsoft Azure)
shared this idea
·
this item could be combined with this one: https://feedback.azure.com/admin/v3/suggestions/33531871/activity