開發(fā)人員有時(shí)候使用類似下面SQL將字符串轉(zhuǎn)換為日期時(shí)間類型，乍一看，這樣的SQL的寫法是沒有什么問題的。但是這樣的SQL其實(shí)有時(shí)候就是一個(gè)定時(shí)炸彈，隨時(shí)可能出現(xiàn)問題（），下面簡單對這種情況進(jìn)行一個(gè)簡單概括。

SELECT CONVERT(DATETIME, '2020-01-13 6:46:42');

如果你將連接數(shù)據(jù)庫的登錄名的默認(rèn)語言修改為Aribc，然后去執(zhí)行上面SQL語句，就會遇到錯(cuò)誤，為什么呢？

為什么上面SQL的日期轉(zhuǎn)換出錯(cuò)了呢？其實(shí)是因?yàn)榈卿浢薷哪J(rèn)語言后，會話對應(yīng)的date_format變化了，從mdy變成了dmy，所以上面轉(zhuǎn)換就報(bào)錯(cuò)了，有時(shí)候不報(bào)錯(cuò)，但是可能轉(zhuǎn)換成一個(gè)錯(cuò)誤日期，產(chǎn)生了邏輯錯(cuò)誤，這個(gè)反而是一個(gè)跟糟糕的隱性錯(cuò)誤。等你發(fā)現(xiàn)的時(shí)候，可能已經(jīng)產(chǎn)生大量錯(cuò)誤數(shù)據(jù)了。

SELECT session_id
  ,program_name
  ,client_interface_name
  ,language
  ,date_format
FROM sys.dm_exec_sessions
WHERE session_id = 53;

關(guān)于不同語言的默認(rèn)date_format，可以使用下面命令查看：

sp_helplanguage 'us_english'

另外一種情況，如果當(dāng)前會話使用SET命令修改過DATEFORMAT，也會遇到這個(gè)錯(cuò)誤，如下所示：

SET DATEFORMAT DMY;
GO
SELECT CONVERT(DATETIME, '2020-01-13 6:46:42');

這種情況就比較復(fù)雜了，有可能是某一段SQL里面設(shè)置了DATEFORMAT，導(dǎo)致整個(gè)會話后面的日期格式全部變化了。所以上面這種SQL的“健壯性”就比較差，在平時(shí)就要避免寫出這樣的SQL，如果你使用這樣的SQL，不管是會話的默認(rèn)語言變化了，還是當(dāng)前會話的DATEFORMAT變化了，都不會產(chǎn)生錯(cuò)誤或邏輯錯(cuò)誤。

SELECT CONVERT(DATETIME,'2020-01-13 6:46:42', 120)。

平時(shí)遇到這種日期轉(zhuǎn)換，就一定要明確指定轉(zhuǎn)換格式，讓其不要受會話的DATEFORMAT變化影響，書寫健壯、可靠的SQL語句，下面這兩個(gè)簡單SQL的細(xì)微差別，也可判別一個(gè)人是否用有書寫健壯性SQL的意識！

SELECT CONVERT(DATETIME, '2020-01-13 6:46:42');
SELECT CONVERT(DATETIME, '2020-01-13 6:46:42', 120)

總結(jié)

以上所述是小編給大家介紹的解析SQL Server中SQL日期轉(zhuǎn)換出錯(cuò)的原因，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時(shí)回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！
如果你覺得本文對你有幫助，歡迎轉(zhuǎn)載，煩請注明出處，謝謝！