由於語言環境而將字符串轉換爲日期時間時出錯

我在SQL Server 2008 R2 Express的特定實例中的語言環境中遇到了很多困難。由於語言環境而將字符串轉換爲日期時間時出錯

我在英國和以下失敗：

SELECT CAST('2012-12-31' AS DATETIME)

錯誤消息：

varchar數據類型爲datetime數據類型的轉換導致的失範圍值。

Windows服務器語言環境是英式英語。我的登錄語言環境是英式英語。如果重要，整理「是Latin1_General_CI_AS。

數據庫'語言'是英語（美國），但是這與其他服務器上的另一個實例相同，並且上述SQL不會失敗。

有什麼想法？

來源

2012-05-30 Dillorscroft

對於用戶建立數據庫連接 - SQL用戶 - 將語言設置爲英語。

這是發出查詢

一種方法來檢查，如果這是一個問題，具體到連接的SQL用戶的設置... Management Studio中運行此並登錄，誰發出查詢的SQL用戶

SET LANGUAGE English 
SELECT CAST('2012-12-31' AS DATETIME)

如果一切正常，設置SQL用戶的默認語言適當

來源

2012-05-30 15:00:10 jglouie

我不同意解決方案是讓所有用戶使用相同的語言。如果他們的語言是爲了其他目的而設置的，那麼該怎麼辦？修復每個用戶也很乏味，因爲每次創建新用戶時，代碼可能只會在修復之前就開始失敗。如果您修復了代碼，則可以解決問題。 –

這不是針對所有用戶的。這是一個SQL登錄帳戶 – jglouie

是的，當你添加一個新的SQL登錄帳戶並且他們的語言設置爲英國時，請猜測你的代碼再次開始做什麼？ –

你應該明確定義的日期格式上的轉換，在這種情況下是120：

SELECT CONVERT(DATETIME,'2012-12-31',120)

您可以在此頁面看一看看到更多的日期格式： http://msdn.microsoft.com/en-us/library/ms187928.aspx

來源

2012-05-30 14:57:52 Lamak

的問題是，這是應該是一個活的翻版系統。實時設置實際上工作，似乎是使用相同的配置。我意識到我可以投等，但我不能改變鏡像系統。 – Dillorscroft

不要使用YYYY-MM-DD日期文字，總是使用YYYYMMDD。這將永遠不會失敗，不分區域，日期格式設置，語言設置，區域設置等：

SELECT CAST('20121231' AS DATETIME);

值得讀便叫：http://sqlblog.com/blogs/aaron_bertrand/archive/2009/10/16/bad-habits-to-kick-mishandling-date-range-queries.aspx

來源

2012-05-30 15:00:30

以及當用戶將日期保存爲YYYYDDMM時會發生什麼？ sql永遠不會知道，你將會得到很多很難找到的錯誤。作爲lamak說，以日期格式轉換更安全。 –

@Thierry當用戶通過'20121208'作爲明確標準時，他們意味着8月12日而不是12月8日，將存儲錯誤的日期。如果他們通過「20121612」，那麼他們將收到一個錯誤。順便說一句，當用戶將「2012-12-08」傳遞給Lamak的方法時，就會發生這些事情。不同之處在於YYYYMMDD將總是被SQL Server解釋，而YYYY-MM-DD有時會被錯誤地解釋。 –

我明白了，謝謝你的信息。我問，因爲我在哪裏工作，區域設置是YYYYDDMM，因爲我們強制執行它給我們的客戶，但默認情況下它的本地設置是DDMMYYYY，並且它經常導致對日期的混淆。 –

由於語言環境而將字符串轉換爲日期時間時出錯

回答

相關問題