If I close SSMS uncleanly with documents open, I get a dialog asking me if I want to recover or not. I can choose not to recover some or all of them. Are you saying this dialog takes too long to load, or is not being shown?
Also, I think you can turn off auto recover altogether in tools\options\AutoRecover
I tried to repro your steps and got lost in the step - "Start typing anything.." Could you rephrase it?
In addition, could you share a screenshot?
so this is a bit lame but in SSMS 17.x you need to set this environment variable to the DNS suffix of blob storage for the cloud you want: AZUREBLOBDNSNAME
The default is blob.core.windows.net.
For US Government cloud I think you would set AZUREBLOBDNSNAME environment variable to "blob.core.usgovcloudapi.net"
I think this is fixed in the SSMS 18 preview, can you try it there?
this is the current list from the v18 NuGet
We are looking into this one.
There's a devious way to change the server name in the connection dialog - switch to the Additional Connection Parameters tab and add "Data Source=servername,portnumber"
That may not unblock this entire scenario, though.
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
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.