从昨天开始,我开始遇到与SQL Server 2008中的日期格式相关的错误。
直到昨天,以下情况仍然有效。
EXEC MyStoredProc '2010-03-15 00:00:00.000'
从昨天开始,我开始超出范围错误。在调查之后,我发现上面的日期现在被解释为“第15个月的第3个”,这将导致超出范围的错误。
我已经能够使用以下格式使用“T”修复此问题。
EXEC MyStoredProc '2010-03-15T00:00:00.000'
通过使用此格式,其工作正常。基本上我想要找出的是,如果有一些Hotfix或补丁可能导致这种情况,因为我使用前面提到的格式的所有查询都已经工作了几个月。
此外,这不是公司某人更改的设置,因为这种情况发生在所有SQL 2005/2008服务器上
答案 0 :(得分:2)
会话的语言设置可以更改此设置。
--This works
set language english
select cast('2010-03-15 00:00:00.000' as datetime)
--This doesn't
set language french
select cast('2010-03-15 00:00:00.000' as datetime)
T介于两者之间,它始终有效。如果你想要一个空格,那就省略连字符。
--This works
set language english
select cast('2010-03-15T00:00:00.000' as datetime)
--This works
set language french
select cast('2010-03-15T00:00:00.000' as datetime)
--This works
set language english
select cast('20100315 00:00:00.000' as datetime)
--This works
set language french
select cast('20100315 00:00:00.000' as datetime)
所以我的猜测是你的应用程序已更改...或客户端计算机上的某些设置。
答案 1 :(得分:1)
听起来你有各种日期风格 - yyyy / MM / dd vs yyyy / dd / MM - 这似乎是英国和美国风格的反向日期。
如果所有服务器都显示相同的行为,则可能只是执行代码的计算机发生了更改,而不是网络中的其他计算机/ SQL服务器。
仔细检查日期格式或文化设置是否是您希望它们在该计算机上的设置。假设它们不是,您可以从事件日志或Windows Update历史记录中了解周末对机器所做的更改。
答案 2 :(得分:1)
要避免这些问题,您应始终指定日期格式。出于您的目的,您应该使用:
SET DATEFORMAT ymd;
请参阅this MSDN page - 请注意
的评论日期, datetime2 和 datetimeoffset 数据类型不支持ydm
因此,如果您正在使用其中一种数据类型,则可能必须使用其他格式。
答案 3 :(得分:1)
整理可以影响日期和语言。
要检查服务器安装的默认语言,请使用以下SQL命令:
sp_configure 'default language'
如果结果值为0,则默认语言为美国英语。如果结果不为0,请运行以下SQL命令以查找已安装的默认语言设置和使用的日期格式:
select name ,alias, dateformat
from syslanguages
where langid =
(select value from master..sysconfigures
where comment = 'default language')
现在关于系统更新更新,那些是在2007年调整到当时强制执行的DST更改。 特定于机器:您可以将特定机器上的时钟设置为不调整DST - 检查每台机器的设置(例如,它在控制面板上的Windows / XP下的日期和时间)。
如果您选择使用短划线,则日期可能会出现问题。如果你拿出破折号,SQL Server永远不会误解数据:
EXEC MyStoredProc '2010-03-15 00:00:00.000'
这可能会得到负时间偏移的时间,在这种情况下无效。(只是一个猜测) VS
EXEC MyStoredProc '20100315 00:00:00.000'
请注意,那里的T是ISO8601格式,因此允许使用短划线。
答案 4 :(得分:0)
好的,我刚刚在Simons SQL博客(http://cli.gs/hqaR4)上阅读了有关此特定问题的帖子。所以这个问题的一个解决方案是使用新的DATETIME2数据类型,因为它理解不使用MDY日期的语言