爲何你SQL Server中SQL日期轉換出錯了呢？

開發人員有時候使用相似下面SQL將字符串轉換爲日期時間類型，乍一看，這樣的SQL的寫法是沒有什麼問題的。可是這樣的SQL其實有時候就是一個定時炸彈，隨時可能出現問題（），下面簡單對這種狀況進行一個簡單歸納。

 

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

 

 

若是你將鏈接數據庫的登陸名的默認語言修改成Aribc，而後去執行上面SQL語句，就會遇到錯誤，爲何呢？

 

 

 

爲何上面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;

 

 

關於不一樣語言的默認date_format，可使用下面命令查看：

 

sp_helplanguage 'us_english'

 

 

另一種狀況，若是當前會話使用SET命令修改過DATEFORMAT，也會遇到這個錯誤，以下所示：

 

SET DATEFORMAT DMY;

GO

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

 

 

 

這種狀況就比較複雜了，有多是某一段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)