为何CURRENT_DATE在SSIS中可用但在SQL Server中不可用？

以下是几种最可能的原因：

• ODBC驱动的自动转换：如果你的Execute SQL Task用的是ODBC连接管理器，而非SQL Server原生的OLE DB连接，ODBC驱动会自动把ANSI标准的CURRENT_DATE转换成SQL Server能识别的等效语句（比如CAST(GETDATE() AS DATE)）。SSMS用的是原生SQL Server协议连接，不会做这个转换，所以直接运行会报错。
• SSIS表达式预解析：如果这个SQL语句是通过SSIS表达式生成的（比如在任务的SQLStatementSource里用了表达式配置），SSIS引擎可能在执行前就把CURRENT_DATE替换成了SQL Server支持的函数或变量（比如GETDATE()或者系统变量@[System::StartTime]），你在编辑器里看到的只是未解析的原始文本。
• 运行环境的数据库并非你以为的SQL Server：虽然你用SSMS连接的是SQL Server，但SSIS包实际运行时连接的可能是其他支持CURRENT_DATE的数据库（比如PostgreSQL、MySQL），或者是较新版本的SQL Server/Azure SQL Database——这类环境已经支持CURRENT_DATE作为CAST(SYSDATETIME() AS DATE)的别名，而你用SSMS 2014连接的是旧版SQL Server，所以不支持。

• 先确认所有使用CURRENT_DATE的Execute SQL Task的连接管理器类型：如果是ODBC，迁移到云时要么继续使用兼容的ODBC驱动（比如Azure SQL的官方ODBC驱动），要么手动把CURRENT_DATE替换成SQL Server/Azure SQL支持的写法（CAST(GETDATE() AS DATE)、CURRENT_TIMESTAMP或SYSDATETIME()，按需选择）。
• 全面排查所有SSIS包中的SQL语句：除了CURRENT_DATE，还要找CURRENT_TIME、SESSION_USER这类ANSI标准函数，确认它们是否都是通过驱动转换或SSIS表达式处理的。
• 验证实际运行环境的数据库版本：如果原运行环境是SQL Server 2022+或Azure SQL Database，CURRENT_DATE本身是支持的；如果是旧版SQL Server（2016及以前），迁移后必须替换这些函数。
• 迁移后做全量测试：在云SSIS运行环境（比如Azure-SSIS Integration Runtime）中测试所有涉及这类函数的任务，确保转换逻辑依然生效。

内容的提问来源于stack exchange，提问作者Dallas Caley