what version of SSMS and SMO are you using? This works for me in SSMS 17.7.
Does adding a call to index.Alter() before calling Rebuild change the behavior?
Do you happen to know if visual studio 2013/2015 exhibit the same behavior?
this item could be combined with this one: https://feedback.azure.com/admin/v3/suggestions/33531871/activity
maybe this item becomes combined with this one: https://feedback.azure.com/admin/v3/suggestions/33532654/activity
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?
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.
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.
Do you mean some other settings than what are included in Tools/Options/Query Results/Sql Server/Results to Grid ?
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).
Thank you for the suggestion. Vulnerability Assessment can now be run using SSMS 17.4.