.Net 4.5应用能否兼容升级后的SQL Server 2017数据库？

99%的场景下你不需要对现有.NET 4.5应用做任何代码调整，SQL Server 2012升级到2017后应用可以直接正常运行，只有非常边缘的特殊场景需要做小范围适配。

• SQL Server全系列自带向后兼容能力，SQL Server 2017支持将数据库兼容级别设置为110（也就是SQL Server 2012的原生兼容级别），这个级别下所有T-SQL语法、查询执行行为和2012完全一致，不会出现语法报错、执行结果偏差的问题。你甚至可以在升级完成后很长一段时间内都保持110兼容级别，等确认所有业务稳定了再考虑升到2017原生的140兼容级别。
• .NET Framework 4.5内置的System.Data.SqlClient数据提供程序本身是跨SQL Server版本兼容的，从最早的SQL Server 2000到后续的2019、2022版本，底层TDS通信协议都是打通的，基础的连接、增删改查、事务操作不会出现任何适配问题。主流的.NET框架下的数据组件，比如EF6、Dapper、老版本NHibernate，对接SQL Server 2017也都没有已知的兼容bug。

• 代码里硬编码了SQL Server版本校验逻辑：比如你之前写了拦截逻辑，只允许连接版本号为11.x（SQL Server 2012的版本段）的数据库实例，这种逻辑需要放开版本限制，不然会被自己写的校验挡住连接。
• 用到了在SQL Server 2017中正式被移除的废弃功能：这类功能基本都是SQL Server 2005甚至更早版本就标记为废弃的，比如老旧的sp_addrole存储过程、SQL Mail、旧版非ANSI的外连接写法*=/=*，如果你的代码里还在调用这类早就该淘汰的语法，需要替换成新的等价写法。
• 升级后直接把兼容级别切到140时的行为差异：140兼容级别修复了几个老版本存在了很多年的冷门bug，比如部分场景下datetime隐式转换的精度偏差、递归CTE的结果计算错误，如果你的业务代码刚好依赖这些bug的错误输出（这种情况极其罕见），才会出现结果不符合预期的问题。

• 升级前先跑一遍微软官方的SQL Server升级评估工具，扫一遍现有实例里的库有没有用到废弃功能、不兼容的语法，提前排雷就行，不用提前改代码。
• 刚升级完先把数据库兼容级别保持在110，跑1-2周观察应用日志没有异常报错，再根据需要决定要不要升到140兼容级别，不要升级完立刻切最高兼容级别。
• 上线前做一轮核心业务场景的回归测试，重点覆盖复杂查询、报表统计、批量数据导入导出这类场景就足够，不需要做全量代码改造。

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