2

我不明白发生了什么。

这会产生错误

create procedure sp_test
as
/*
   /*
      a
   */
   e'
*/
begin
print''
end
go

“消息 102，级别 15，状态 1，过程 sp_test，第 13 行 'go' 附近的语法不正确。”

虽然这有效

create procedure sp_test
as
/*
   /*
      a
   */
   e
*/
begin
print''
end
go

为什么如果我在主评论中有两个嵌套评论我不能有 ' 符号？我使用 VS Sql compare 来生成 db 脚本发现了这个错误，并且在此之后不可能有任何其他 GO。

而是使用 Sql Management 它将生成没有 GO 的单个 sp_test 脚本。

4

2 回答 2

1

这一定是 SQL Server Management Studio 中的错误。

该GO语句不是 SQL Server 知道如何处理的真实语句，而是编辑器（例如 Management Studio 和命令行客户端）用来将大查询分隔为较小部分的约定。

然后将这些较小的部分按顺序一一执行。

因此，如果GO命令实际上被发送到 SQL Server 执行，它将不知道如何处理它，从而给你你得到的错误。

在 Management Studio 2014 中，嵌套注释的语法着色很好，但内部撇号的存在会使试图将查询分隔成更小的部分的代码出错。

因此，我认为这里的错误是尝试拆分GO语句的代码实际上不支持嵌套注释，因此被它们的存在绊倒了。基本上它似乎认为注释在 inner 之后结束*/，这是错误的，然后撇号被认为是一个没有结尾的字符串的开头，然后封装了后面的所有内容，包括GO命令。

因此，撇号后的所有内容都将发送到 SQL Server。SQL Server 确实支持嵌套注释，因此它会将GO命令视为它不支持的语句，因此会出现错误。

我在这里使用 Microsoft Connect 报告了这一点：SQL Server 2014 Management Studio, when delimiting on GO command, doesn't handle nested comments。

于 2016-09-09T08:39:20.383 回答
0

虽然 SQL Server 本身允许嵌套块注释，但 SSMS、SQLCMD.EXE 和可能的 SMO 使用的批处理解析代码中存在一个错误，它不能完全处理这些嵌套块注释。我强调“完全”，因为该代码将在一定程度上处理它们。这完全取决于它们的嵌套方式以及嵌入GO或撇号等的位置。有些组合有效，而另一些则无效。例如，您的非工作测试的以下改编确实有效，因为我添加了第二个嵌套注释：

create procedure sp_test
as
/*
   /*
      a
   */
   /*
   e'
   */
*/
begin
print''
end
go

我在 3 月份将这个错误发布到 Microsoft Connect，但我怀疑它是否会被视为有足够的优先级让开发人员专注于，可悲的是：

嵌套块注释的第二半部分中的“GO”破坏了 SSMS 和 SQLCMD 中的批处理解析

PS 应该注意的是，旧的 OSQL.EXE 似乎没有这个特殊的解析问题，尽管我仍然不建议使用它;-)。

于 2016-09-09T16:45:51.640 回答