SQL语法错误：'Union'语法不正确，求解决方案

嘿，我来帮你捋捋这个棘手的问题——你明明没写UNION/UNION ALL语句，却碰到了这个语法错误，确实挺让人摸不着头脑的。咱们一步步拆解可能的原因和解决方向：

• 注释格式的隐藏陷阱
  看你提供的代码片段，有不少被注释掉的内容，比如/* WHERE */、/* T0.TaxDate */、/*SELECT FROM [dbo].[OINV] T1*/这类。SQL解析器对注释的要求很严格，如果某个注释没有正确闭合（比如漏写了*/），或者注释里的内容意外破坏了整体语法结构，就可能让解析器误把注释里的内容当成有效代码处理。比如要是某个未闭合的注释后面刚好残留了和UNION相关的代码片段，就会触发这个报错。
  建议你先检查所有注释的完整性，确保每个/*都有对应的*/，尤其是那些被注释掉的完整SQL语句，有没有漏写闭合符号。

• 变量赋值的语法问题
  你的代码里有SET @StartDate = ''这种操作——把空字符串赋值给DATETIME类型变量本身就不合法，SQL Server会尝试隐式转换空字符串为日期，这本身就可能引发语法或转换错误。虽然这不是直接的UNION错误，但有时候SQL解析器的报错提示会有误导性，把其他语法问题关联到错误的关键字上。另外，IF(@StartDate = '') SET @StartDate = ...里的...如果是不完整的赋值语句，或者后续内容有语法问题，也可能触发奇怪的报错。
  先修正变量赋值：如果要给日期变量设默认值，应该用SET @StartDate = NULL或者合法的日期值，比如'1900-01-01'。

• 代码残留或编辑器的自动补全问题
  有时候编辑器的自动补全、代码模板残留，或者你之前删除了UNION语句但没清理干净，都会导致解析器误识别。比如你片段里有多个SELECT FROM [dbo].[OINV]的注释，会不会之前的代码里是用UNION连接这些查询，后来被注释掉但没处理彻底？

• 报错提示的位置误导
  别完全迷信报错里的“Union”关键字指向——有时候SQL解析器在处理其他语法错误时，会把报错指向错误的位置或关键字。比如如果你的IF语句后面的代码块没加BEGIN/END，后续内容又有语法问题，就可能触发这类误导性报错。

下一步排查建议 #

1. 先把所有注释暂时删除，运行简化后的代码，看是否还报错。如果不报错了，再逐个加回注释，定位是哪个注释导致的问题。
2. 修正所有DATETIME变量的赋值逻辑，确保赋值的是合法的日期值或NULL。
3. 如果方便的话，提供完整的代码——毕竟你给出的片段里SET @StartDate = ...是不完整的，后面的内容很可能才是问题的关键。

内容的提问来源于stack exchange，提问作者Hüsrev Alcan