開發人員有時候使用類似下面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,120)

總結

以上所述是小編給大家介紹的解析SQL Server中SQL日期轉換出錯的原因，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回覆大家的。在此也非常感謝大家對我們網站的支援！
如果你覺得本文對你有幫助，歡迎轉載，煩請註明出處，謝謝！