开发人员有时候使用类似下面SQL将字符串转换为日期时间类型,乍一看,这样的SQL的写法是没有什么问题的。但是这样的SQL其实有时候就是一个定时炸弹,随时可能出现问题(隐藏的炸弹而已,只是等触发条件而已),下面简单对这种情况进行一个简单概括。
SELECT CONVERT(DATETIME, '2020-01-13 6:46:42');
如果你将连接数据库的登录名的默认语言修改为Aribc,然后去执行上面SQL语句,就会遇到错误,为什么呢?
![5e1ca2ef2ccfeac11472fbb91a62f1cc.png](https://i-blog.csdnimg.cn/blog_migrate/4a47c4baab9f5193e3865ae294a1ca92.jpeg)
为什么上面SQL的日期转换出错了呢?其实是因为登录名修改默认语言后,会话对应的date_format变化了,从mdy变成了dmy,所以上面转换就报错了,有时候不报错,但是可能转换成一个错误日期,产生了逻辑错误,这个反而是一个更糟糕的隐性错误。等你发现的时候,可能已经产生了大量错误数据了。
SELECT session_id
,program_name
,client_interface_name
,language
,date_format
FROM sys.dm_exec_sessions
WHERE session_id = 53;
![ea962932ce354b3454e65934d6a3fed0.png](https://i-blog.csdnimg.cn/blog_migrate/ed85231477608a2e05f89150957b0a04.jpeg)
关于不同语言的默认date_format,可以使用下面命令查看:
sp_helplanguage 'us_english'
另外一种情况,如果当前会话使用SET命令修改过DATEFORMAT,也会遇到这个错误,如下所示:
SET DATEFORMAT DMY;
GO
SELECT CONVERT(DATETIME, '2020-01-13 6:46:42');
![2fd9b3d2294b9a1c0c02a7242ea819ef.png](https://i-blog.csdnimg.cn/blog_migrate/17bdc926a80805f3e09d5e9cd4ca867a.jpeg)
这种情况就比较复杂了,有可能是某一段SQL里面设置了DATEFORMAT,导致整个会话后面的日期格式全部变化了。所以上面这种SQL的“健壮性”就比较差,在平时就要避免写出这样的SQL,如果你使用这样的SQL,不管是会话的默认语言变化了,还是当前会话的DATEFORMAT变化了,都不会产生错误或逻辑错误。
SELECT CONVERT(DATETIME,'2020-01-13 6:46:42', 120)。
平时遇到这种日期转换,就一定要明确指定转换格式,让其不要受会话的DATEFORMAT变化影响,书写健壮、可靠的SQL语句,下面这两个简单SQL的细微差别,虽不能就一定判别一个人SQL技能水平的高低!但是,细微之处见风范,毫厘之优定乾坤!
SELECT CONVERT(DATETIME, '2020-01-13 6:46:42');
SELECT CONVERT(DATETIME,'2020-01-13 6:46:42', 120)