Activity overview
Latest activity by 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. / comments
This idea has been posted to redgate.uservoice.com. Feel free to vote for it there. It is under the "SQL Toolbelt Essentials" discussion.
Document the columns of a table-value function
Enhancement suggestion: when documenting a table-valued function include a Columns section similar to when documenting a table.All the metadata exists to enable documentation of the columns returne...
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. / comments
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 versio...
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). / comments
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 trust...
How to avoid VIEW SERVER STATE permission error using SQL Doc?
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 permissio...
Jessica, Thanks for answering the question and confirming SQL Data Compare cannot write back to a source control repository. (Although it can write to a working folder which may be under source control.) The difference in Jonathan's scenario and mine are that I have no way to use filters, deciding what to deploy where, since it is data in the same table object (rather than objects in different schemas) that I want to control by environment. / comments
Jessica, Thanks for answering the question and confirming SQL Data Compare cannot write back to a source control repository. (Although it can write to a working folder which may be under source con...
Alex, Thanks for the reference. While similar the scenario was different. Regards, Bob Good / comments
Alex, Thanks for the reference. While similar the scenario was different. Regards, Bob Good
Can SQL Data Compare commit changes to source control repositories?
Scenario - We have a table of configuration data whose content varies as it gets promoted. We would like to source control environment specific data in a branch separate from where we are source co...
I have a similar problem that I suspect is due to the encoding of the script used to create the object in each of the databases. (As in ASCII vs UTF-16 vs UTF-8).
Try unchecking the ignore whitespace option in the comparison. Then re-compare to see what the differences are.
There is a post related to encoding that resulted in Bug Report reference SC-7653. / comments
I have a similar problem that I suspect is due to the encoding of the script used to create the object in each of the databases. (As in ASCII vs UTF-16 vs UTF-8).
Try unchecking the ignore whitespa...
Also, I now see similar information, confirming issues with branching, in the SQL Source Control 3 forum from last May 2012. / comments
Also, I now see similar information, confirming issues with branching, in the SQL Source Control 3 forum from last May 2012.