原因是,dmy導致您的字符串文字被解釋爲第一天 - 所以這是10月8日而不是8月10日。
解決方案是始終使用明確的日期文字格式(或正確使用類型化參數,而不是首先處理字符串翻譯)。
WHERE dtinsertdate = '20120810 22:48:41.047';
正如你已經發現,在你的日期那些短線可以根據語言/日期格式設置的實際值進行不同的解釋。
另一種方法是保持破折號,但注入一件T,而不是一個空格,如:
WHERE dtinsertdate = '2012-08-10T22:48:41.047';
你原來是更具可讀性,但它只能保證,如果你使語言和日期格式固定工作(例如試用SET LANGUAGE FRENCH;
)。試試這個實驗:
SET DATEFORMAT DMY;
DECLARE @d DATETIME = '2012-08-10 22:48:41.047'
SELECT MONTH(@d);
GO
SET LANGUAGE FRENCH;
DECLARE @d DATETIME = '2012-08-10 22:48:41.047'
SELECT MONTH(@d);
GO
SET DATEFORMAT MDY;
DECLARE @d DATETIME = '2012-08-10 22:48:41.047'
SELECT MONTH(@d);
GO
SET DATEFORMAT MDY;
SET LANGUAGE ENGLISH;
DECLARE @d DATETIME = '2012-08-10 22:48:41.047'
SELECT MONTH(@d);
GO
有時候結果是8,有時效果10.現在再次用兩種格式我上面提出的一個嘗試 - 結果始終是8
我有很多的有趣的細節值得閱讀的位置:
http://sqlblog.com/blogs/aaron_bertrand/archive/2009/10/16/bad-habits-to-kick-mishandling-date-range-queries.aspx
但你在談論,永遠,永遠,永遠使用以下格式的日期/時間文字一個具體的問題,我不認爲任何別人安全。
對於日期+時間:
YYYY-MM-DDTHH:MM:SS...
YYYYMMDD HH:MM:SS...
僅供日期:
YYYYMMDD