您好,登錄后才能下訂單哦!
開發人員有時候使用類似下面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)
總結
以上所述是小編給大家介紹的解析SQL Server中SQL日期轉換出錯的原因,希望對大家有所幫助,如果大家有任何疑問請給我留言,小編會及時回復大家的。在此也非常感謝大家對億速云網站的支持!
如果你覺得本文對你有幫助,歡迎轉載,煩請注明出處,謝謝!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。