Stephen A
My feedback
10 results found
-
5 votesStephen A
shared this idea
·
-
11 votesStephen A
shared this idea
·
-
27 votes
An error occurred while saving the comment Stephen A
supported this idea
·
-
22 votesStephen A
shared this idea
·
-
3 votesStephen A
shared this idea
·
-
9 votesStephen A
shared this idea
·
-
3 votesStephen A
shared this idea
·
-
7 votes
An error occurred while saving the comment Stephen A
commented
The ability to "copy override" is needed - period!
Having multiple similar servers, at lower levels I need to keep 2 panes open to "copy", as in manually replicate (noting another poster's difficulty, like mine, in finding all those places where someone touched something).
This is 2016 after all, so it would seem to be a no-brainer to "Show overrides", multi-select, clone, adjust if necessary.
While you're there, RG, let me find where a departed colleague shoved his email address, and give me a single page where I can work through removing/replacing. I dread to think how bad it would be for folks with over 20 servers (I have that few) where a departed dba's email may be littered...
Stephen A
supported this idea
·
-
176 votes
currently under investigation
Stephen A
supported this idea
·
-
42 votes
Daniel Rothig
responded
When we’ll be improving the alert configuration UI, we’ll keep that use case in mind
An error occurred while saving the comment Stephen A
commented
ReportServerTempDB should be excluded from the backup warning and integrity check overdue, by default.
As many SQL Instances will have the pair of SSRS DBs, these don't readily fit into the drill-down by server and instance paradigm the current UI suffers from. We should be able to invert the tree and set our alerting preferences at the database-across-all-instances level first, then override it if and when needed. This applies to ALL System Databases, of course. Taking that further, when a software vendor (such as I'm employed by) has a default deployment DB name across all customer-specific instances, the tree-inversion paradigm would also work well for our alerting configurations - they're typically the same - so an opt-in-by-User-DB to the inverted approach would be greatly appreciated.
Taking User database treatment even further - if we can assign a friendly name to a database on an instance and collect all those databases the customer wanted their name in/as, instead of the default name, again, our alerting by database first would be much more efficiently handled.
Stephen A
supported this idea
·
Totally agree - except I'm dealing with 3000 line complex, multi-table insert-updates for batches of calculations. I have no idea whatsoever which resource is involved...