zoukankan      html  css  js  c++  java
  • SQL Server ->> 内置标量函数TRY_PARSE、TRY_CAST和TRY_CONVERT的各自特点和区别

    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
       210,860 
    ABC

    可以看到结果中对于第5行的转换TRY_PARSE没能把数字前后类似于空格的特殊字符忽略。这点上TRY_CAST应该说做得更加好。

  • 相关阅读:
    我认知的javascript之函数调用
    table 的宽度设置无效
    【转】微信读书排版引擎自动化测试方案
    RocksDB原理及应用
    ElasticSearch 架构及应用简介
    芝加哥大学论文写作指南 简述
    python 常用模块
    Flask-SQLAlchemy安装及设置
    selenium设置程序失败后重启
    获取临时IP加入临时列表使用
  • 原文地址:https://www.cnblogs.com/jenrrychen/p/4976429.html
Copyright © 2011-2022 走看看