SQLServer-》内置标量函数TRY_PARSE、TRY_CAST和
TRY_CONVE。。。
SQL Server到了⽬前的2014版本有三个函数是⽤来转换数据格式的。虽说之前版本中已经有CAST和CONVERT这两个函数来⼲这个事情。问题是，⼀旦往⽬标数据类型转换失败就会造成报错。
TRY_PARSE、TRY_CAST和TRY_CONVERT的共同特点：
1）即便转换失败也不会造成整个语句报错，只会在⽆法转换的情况下输出NULL值；
TRY_PARSE：
TRY_PARSE是⽤于将字符串类型的数据转换成时间或者数值类型的数据。它是⼀个基于.NET CLR Runtime的标量函数。语法是
TRY_PARSE(<string/string column> AS <data_type> [USING <culture>])
下⾯做⼀个字符串转时间的实验：
SQL Server 版本：
Microsoft SQL Server 2014
Enterprise Edition (64-bit) on Windows NT 6.3 <X64>
SELECT TRY_PARSE('20150901'AS DATETIME), TRY_CAST('20150901'AS DATETIME), TRY_CONVERT(DATETIME,'20150901')
SELECT TRY_PARSE('2015/09/01'AS DATETIME), TRY_CAST('2015/09/01'AS DATETIME), TRY_CONVERT(DATETIME,'2015/09/01')
SELECT TRY_PARSE('2015/09/01 14:14:45'AS DATETIME), TRY_CAST('2015/09/01 14:14:45'AS DATETIME), TRY_CONVERT(DATETIME,'2015/09/01 14:14:45')
SELECT TRY_PARSE('2015/09/01 14：14：45'AS DATETIME), TRY_CAST('2015/09/01 14：14：45'AS DATETIME), TRY_CONVERT(DATETIME,'2015/09/01 14：14：45') SELECT TRY_PARSE('2015/09/01 14:14:45+0001'AS DATETIME), TRY_CAST('2015/09/01 14:14:45+0001'AS DATETIME), TRY_CONVERT(DATETIME,'2015/09/01 14:14:45+0001')上⾯代码输出的结果如下图所⽰
可以看到TRY_PARSE在将纯数字转为DATETIME的情况下居然失效，这点让我⾮常意外，⽽且我尝
试了DATE类型也是⼀样的结果。
⽽如果加了像"-"或者"/"这样的时间分隔符则三个函数都能转换成功。
还有⼀点让我惊讶的是TRY_CAST和TRY_CONVERT不⽀持带有时区的转换，⽽TRY_PARSE则可以。
⽽当我把第四⾏代码的冒号修改成中⽂下⾯的冒号时则SQL Server辨认不出来。
TRY_CAST和TRY_CONVERT:
这⼀对更多是CAST和CONVERT这对函数的变体，语法上⼀样，只是当⽆法成功转换的时候是报错或者输出NULL值。
三者的区别总结如下：
1）TRY_PARSE只⽀持字符转数值或者时间类型，⽽TRY_CAST和TRY_CONVERT⽀持更多的类型；
2）三者有⼀点⽐较好的就是对于字符的空格处理，只要空格在处在分割符号的前后像“2015/    09/  10
”这样是可以被成功处理的，但是如果空格隔开本⾝就是⼀个整体的数据值部分，则全部不能识别，像“2015/0  9/10”。
2）TRY_PARSE由于是CLR写的函数，对于源数据的数据格式⽀持⽐较⼴或者要求⽐较宽松，⽽TRY_CAST和TRY_CONVERT则要求⽐较严格。这点从上⾯的例⼦中，TRY_PARSE⽀持带有时区的时间格式⽽其他两个不⽀持就可以看出。⽽TRY_PARSE的⽀持范围远不⽌于此。
下⾯这个例⼦就证明了TRY_PARSE是仅最⼤的努⼒和可能去转换数据，⽽后两者则需要很严格数据格式
SELECT TRY_PARSE('Thursday, 19 Nov 2015'AS DATETIME)
SELECT TRY_CONVERT(DATETIME, 'Thursday, 19 Nov 2015');
-------------------------------------- update 2015/12/09 ----------------------------------------------
TRY_PARSE和TRY_CAST在把字符转换成数值这⼀功能上，TRY_PARSE在某种情况下要⽐TRY_CAST差。这⾥做个实验。
SELECT  Column1,
TRY_CAST(Column1 AS FLOAT) AS TRY_CAST,
TRY_CAST(REPLACE(Column1,',','') AS FLOAT) AS TRY_CAST_REMOVE_COMMA,
TRY_PARSE(Column1 AS FLOAT) AS TRY_PARSE,
TRY_PARSE(REPLACE(Column1,',','') AS FLOAT) AS TRY_PARSE_REMOVE_COMMA
FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0'
,'Excel 12.0 Xml;HDR=YES;IMEX=1;Database=D:\1.xlsx'
,'SELECT * FROM [sheet1$]');
上⾯语句的结果
我的源⽂件内容是这样的：
Column1
123,456
123456.789
123456
2,464
transform和convert的区别210,860
ABC
可以看到结果中对于第5⾏的转换TRY_PARSE没能把数字前后类似于空格的特殊字符忽略。这点上TRY_CAST应该说做得更加好。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。