How to avoid VIEW SERVER STATE permission error using SQL Doc?

BobGood

Are there settings for SQL Doc that avoid attempting to do operations that require VIEW SERVER STATE permissions?

We are developers (not DBAs) who do not have and will not be granted these permissions on our QA (or production) servers.

Our current .sqldoc file includes the following:

    Option uri="http://sqldoc/project/selections/sections/advancedserversettings/include/" value="False" 

    Option uri="http://sqldoc/project/selections/sections/serversettings/include/" value="False" 

squigley

Good Afternoon!

Unfortunately, there isn't workaround for this as it's one of the requirements:

https://documentation.red-gate.com/sdoc4/troubleshooting/minimum-database-permissions-required-for-the-user-running-sql-doc

I do apologize for the inconvenience that this brings.

BobGood

It is not credible that SQL Doc 5 fails where SQL Compare 13 succeeds. 
For SQL Compare 13; VIEW DEFINITION is the only minimum permission needed.
Even including the following option to exclude trusted assemblies, a VIEW SERVER STATE error was generated when SQL Doc submitted a select query against the sys.trusted_assemblies DMV.

Option uri="http://sqldoc/project/selections/sections/trustedassemblies/include/" value="False"

Defect or proposed feature request:
SQL Doc should determine whether VIEW SERVER STATE permissions exist; and modify its behavior to not issue any DMV query requiring that permission.
Where appropriate, in place of the parts of the documentation (nodes) for which the privileged DMVs are needed, a message stating the item cannot be documented because the user does not have view server state permissions.

Alternative: an option to avoid privileged DMVs should be part of the .sqldoc project file. The difference between this option and that above is how the behavior is determined (by querying for the existence of permissions, or by a project file option). 

BobGood

BTW, the DMV sys.trusted_assemblies was introduced in SQL 2017 (I believe); so SQL Doc 5 must already have a mechanism to select which DMVs to use; and what documentation to produce based on version.

It is not too much of a leap to include consideration of permissions in controlling the behavior of SQL Doc.

rarifiedone

Has there been an update to this?  My DBA said no when I requested View Server State permissions on our sql instance.  They want an explanation for why this permission is required

KenK

Checking to see if there have been any updates.  I have the same issue with SQL Doc, but don't have any issues with SQL Compare.  

Is there a specific object or section I can exclude to get around this error?  

PeteG

Same issue -- any updates??

Louis_Tominack

I am having the same issue.  Please RedGate, offer a work-around to this so our non-DBA users can enjoy this product.

BobGood

This idea has been posted to redgate.uservoice.com. Feel free to vote for it there. It is under the "SQL Toolbelt Essentials" discussion.