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
We have completed this change by appending the Completion Time as a new line in both the messages and the output files. It will be included in the next release of SSMS.
maybe this item becomes combined with this one: https://feedback.azure.com/admin/v3/suggestions/33532654/activity
Hi, thanx for the feedback.
As Ben points out, if you know which fields on the Database object you need, you can use Server.SetDefaultInitFields to make sure the collection is initialized with all those fields in the first query.
Is there a particular scenario, using the latest SMO NuGet, where use of SetDefaultInitFields isn’t sufficient to speed up the query noticeably?
If you have an Intellitrace or XEvents trace I could use for reference it’d be a great help.
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.
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.