SSMS 从我的存储过程中删除 pre-BEGIN 注释答案

【问题标题】：SSMS removing pre-BEGIN comments from my stored proceduresSSMS 从我的存储过程中删除 pre-BEGIN 注释
【发布时间】：2015-02-20 08:05:39
【问题描述】：

我正在运行 SSMS 12.0.2000.8

如果我使用 SSMS 查询编辑器创建一个存储过程（如下面的那个），当我执行/保存它时，BEGIN 之前的 cmets 会被删除：

CREATE PROCEDURE myproc
/* Say goodbye to this comment */
    @var1 int -- this comment will disappear too
AS
BEGIN
   /* This comment is safe */
   select 'hello' -- this too shall endure
END

一位同事正在运行相同版本的 SSMS，但没有出现此类问题。如果我使用sqlcmd.exe 执行他的一个脚本，那么 cmets 也会被剥离。我认为必须有一个全局设置需要更改，但我不知道它可能在哪里。

【问题讨论】：

“然后编写脚本”是什么意思。您是否使用管理工作室将其从数据库中取出？您可能需要检查很多设置。
我不知道我为什么要写“脚本它”——一定是周五下午的大脑放屁。我在 SSMS 查询编辑器中创建 SP，并使用 Script Stored Procedure As... 查看结果。
你检查过所有相关的选项吗？默认情况下，它会遗漏很多东西。现在无法访问 SSMS，所以我无法检查是否也存在。
您的同事是否使用完全相同的数据库并创建完全相同的程序？有些东西可以修改传输中的语句（如 DDL 触发器）。对于它的价值，我无法使用 SSMS 12.0.2456.0 重现它，而且我确实会感到非常惊讶，因为它只需要按原样执行我的命令，而不是以有趣的方式将其分解。如果一切都失败了，请尝试探查器跟踪以验证正确的命令已发送到 SQL Server。
@JamesZ 我不确定您指的是哪个特定选项，但我已经浏览了 SSMS 中的几乎每个菜单项，但到目前为止一无所获。

标签： sql-server stored-procedures ssms

【解决方案1】：

我遇到了同样的问题，发现它是由工具 -> 选项 -> SQL Server 对象资源管理器 -> 脚本 -> 将用户定义的数据类型转换为基本类型引起的。

当这是“真”时，我会丢失我的评论块。当“假”时，我的评论块又回来了。

【讨论】：

奇怪的是，这似乎是当前紧迫问题的首选解决方法：SSMS 2016 16.4 fails when attempting to ALTER/Modify a Stored Procedure: Syntax error in TextHeader of StoredProcedure
在我的情况下，这个设置显然没有任何区别 - 仍然存在问题。

【解决方案2】：

在观察到其他一些奇怪的东西（即with execute as caller被添加到我的脚本中）之后，我做了一些谷歌搜索并找到了答案：

delete \Users\[user]\AppData\Roaming\Microsoft\SQL Server Management Studio\12.0\sqlstudio.bin

警告：您将丢失当前记忆的 SQL Server/用户名/密码列表。

【讨论】：

哇！很好的发现。在 SSMS 2017 中遇到了同样的问题并删除了 .bin 文件修复了它。因为它使用脚本引擎来创建差异，所以它确实搞砸了 SQL 源代码控制。

【解决方案3】：

我用 SQL Server 2008 和 SSMS 12.0.2000.8 对此进行了测试，这是“脚本存储过程为”->“创建到”->“剪贴板”之后的结果：

CREATE PROCEDURE [dbo].[myproc]
/* Say goodbye to this comment */
    @var1 int -- this comment will disappear too
AS
BEGIN
   /* This comment is safe */
   select 'hello' -- this too shall endure
END
GO

在使用脚本工具之前，您是否尝试过使用 sp_helptext 检查 cmets 是否在过程中？

我还检查了选项，找不到与 cmets 相关的任何内容，或者剥离了类似的内容。

【讨论】：

我希望我知道 sp_helptext。无论如何，Visual Studio 2013 中的 SQL Server 对象资源管理器显示该 cmets 没有被剥离，并且在删除 sqlstudio.bin 后问题就消失了。显然，SSMS 脚本引擎让自己陷入了一种奇怪的状态。

【解决方案4】：

虽然指定的解决方案对我不起作用，但它确实为我指明了正确的方向。

对我来说，这种行为只发生在单个 SQL Server 连接上，这是因为“始终加密”设置为“启用”。当我禁用它时，我的 cmets 仍保留在存储过程代码中。

Screen Shot of SSMS 18.4

【讨论】：