不同SQL Server实例中TRY_PARSE处理科学计数法的差异排查

这种同版本实例间的行为差异，核心在于TRY_PARSE和TRY_CONVERT的底层实现逻辑完全不同：

• TRY_CONVERT是SQL Server原生的转换函数，直接使用SQL自身的类型解析规则，不受外部环境影响；
• TRY_PARSE则依赖.NET Framework的System.Convert类完成转换，会受到语言/区域设置、.NET版本等外部因素的制约。

以下是几个最可能导致差异的原因：

1. 服务器/会话的语言与区域设置不同 #

TRY_PARSE在解析字符串时，会严格遵循当前会话或服务器默认的语言/区域文化规则。如果其中一个实例的默认语言不是英语，或者会话的区域设置对科学计数法的格式识别存在差异，就会导致解析失败返回NULL。

比如：若实例默认语言设置为法语（小数点分隔符是逗号），它可能无法正确识别以点作为小数点的科学计数法字符串。

验证方法：
在两个实例上分别执行以下语句对比结果：

-- 查看服务器默认语言
SELECT @@LANGUAGE;
-- 查看服务器排序规则（会影响区域相关解析逻辑）
SELECT SERVERPROPERTY('Collation');

-- 在有问题的实例上临时切换到英语再测试
SET LANGUAGE 'English';
SELECT TRY_PARSE('1.0000000000000000E+00' as float);

如果切换语言后TRY_PARSE返回1，就说明是语言设置导致的问题。

2. .NET Framework版本或补丁差异 #

因为TRY_PARSE依赖.NET Framework的类型转换逻辑，两台机器上的.NET版本不同，或者安装了不同的累积更新补丁，都可能导致解析行为不一致。比如某些.NET补丁修复了科学计数法字符串的解析逻辑，而其中一台机器未安装该补丁。

验证方法：
在两台机器上查看.NET Framework版本（可通过控制面板的“程序和功能”，或注册表路径HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full下的Version值），对比是否一致。

3. SQL Server累积更新（CU）或服务包差异 #

虽然你看到的版本号都是11.0.6020.0（这是SQL Server 2012 SP3的基础版本），但其中一个实例可能安装了后续的累积更新（CU）。微软有时会在CU中修复与.NET交互相关的BUG，包括TRY_PARSE的解析问题。

验证方法：
在两个实例上执行以下语句查看完整版本信息：

SELECT @@VERSION;

完整版本会包含SP和CU编号，比如Microsoft SQL Server 2012 (SP3-CU5) (KB4019089) - 11.0.6566.0，对比两者是否一致。

4. 实例级CLR相关配置差异 #

虽然TRY_PARSE不需要显式启用CLR，但某些与.NET交互相关的实例配置可能间接影响它的行为。比如服务器级别的clr enabled设置（默认禁用但不影响TRY_PARSE基础功能，但若存在自定义CLR组件可能干扰），或者是否有自定义CLR类型/函数修改了默认转换逻辑。

验证方法：
执行以下语句查看CLR配置：

sp_configure 'clr enabled';

同时检查实例中是否存在自定义CLR对象：

SELECT * FROM sys.assemblies WHERE is_user_defined = 1;

总结 #

最常见的原因是语言/区域设置差异，因为TRY_PARSE的行为直接绑定.NET的文化信息，而TRY_CONVERT完全是SQL原生逻辑，不受此影响。建议先从验证语言设置入手排查。

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