日期:2014-05-16  浏览次数:20661 次

[转]关于2147217913 从 char 数据类型到 datetime 数据类型的转换导致 datetime 值越界 的问题解决方法
转自:http://blog.csdn.net/derryzhang/archive/2009/06/29/4306071.aspx

最近收到玻利维亚客户的反馈,运行程序时总提示:
2147217913:La conversión del tipo de datos char a datetime produjo un valor datetime fuera de intervalo.

其英文意思是:
The conversion of a char data type to a datetime data type resulted in an out-of-range datetime value.

中文的意思是:
从 char 数据类型到 datetime 数据类型的转换导致 datetime 值越界。

执行的SQL语句类似:
INSERT INTO Table1(EventType,EventTime)
VALUES('Abnormal error','2008-04-18 11:14:00')

客户的运行环境为:window2000 SP4+ sql200

以上sql 在自己机器上运行,没有任何错误。

根据错误提示,可以初步判断是 SQL 在转换'2008-04-18 11:14:00'时出的问题。我就想 是不是 客户那边操作系统的区域设置的日期格式没设好,导致问题产生的。

我让用户发回了他的区域设置的相关信息:
Time Tab中 Time format 为: hh:mm:ss tt
Date Tab中 Short date format 为: yyyy-MM-dd
Date Tab中 Long date format 为: dddd,dd' de 'MMMM' de 'yyyy

然后我对照我的系统的设置,让用户改成:
Time Tab中 Time format 为: hh:mm:ss
Date Tab中 Short date format 为: yyyy-MM-dd
Date Tab中 Long date format 为: yyyy-MM-dd

用户重新启动计算机后,问题依旧。

马上到网上 google, 没能找到真正能剖析出问题根源的,得到一些线索 SET DATEFORMAT,
查sql 帮助,其作用是:设置用于输入 datetime 或 smalldatetime 数据的日期部分(月/日/年)的顺序。
有效参数包括 mdy、dmy、ymd、ydm、myd 和 dym。美国英语默认值是 mdy。

到此,我明白了 ,客户的SQL Server在转换'2008-04-18 11:14:00'时没有使用 ydm,而是使用了别的格式。

某些网友的答案就是在执行,
INSERT INTO Table1(EventType,EventTime)
VALUES('Abnormal error','2008-04-18 11:14:00')
之前 ,加上 SET DATEFORMAT ymd

但是提供给客户的程序是在很多个国家运行了很久的,没有发生过这种问题,是经历过考验的,而且源代码中 很多地方都是使用“yyyy-mm-dd hh:mm:ss” 这种格式来格式化长日期时间,要在每个地方都加上SET DATEFORMAT ymd 不是最好的解决办法,而且sql文档上已经说明SET DATEFORMAT 只能影响当前会话的转换。因此这种方法对我来说不可取。

那怎么样才能不改程序而能让SQL Sever 能够按 ymd 解释我提供的日期呢? google了又google 还是没找到办法,休息去了。

第二天,又google ,发现了一些线索:
SELECT @@LANGUAGE    --返回当前使用的语言名
SET LANGUAGE        --设置当前会话的语言,会影响DATEFORMAT
DBCC USEROPTIONS --返回当前连接的活动(设置)的 SET 选项。
sp_configure            --显示或更改当前服务器的全局配置设置
sp_helplanguage     --报告有关某个特定的备用语言或所有语言的信息。相当于select * from master..syslanguages

我在我的机器上打开sql 查询分析器,执行 SELECT @@LANGUAGE ,返回结果是 简体中文,而且每次打开sql 查询分析器,其结果都是简体中文。 执行 sp_helplanguage ,知道SQL 简体中文 语言的日期格式为 ymd, 因此在我机器上执行
INSERT INTO Table1(EventType,EventTime)
VALUES('Abnormal error','2008-04-18 11:14:00')
能成功,当我 把语句改成
INSERT INTO Table1(EventType,EventTime)
VALUES('Abnormal error','18-04-2008 11:14:00')
这时就有问题了,
    服务器: 消息 242,级别 16,状态 3,行 1
    从 char 数据类型到 datetime 数据类型的转换导致 datetime 值越界。
    语句已终止。
也就是跟开头 客户遇到的问题一样了。

好了,到此更进一步说明了是SET DATEFORMAT 影响了对字符串日期的正确处理。 而SET LANGUAGE 会联动SET DATEFORMAT 。只要我能 SET LANGUAGE  成正确的语言,那么我的字符串日期就能正确处理。

前面提到,每次我登录sql 查询分析器,执行 SELECT @@LANGUAGE ,返回结果都是 简体中文,我用 sql 的事件探查器分析,每次我登录sql 查询分析器,都有这段显示
-- network protocol: LPC
set quoted_identifier on
set implicit_transactions off
set cursor_close_on_commit off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set language 简体中文        --这里就是关键
set dateformat ymd            --
set datefirst 7

为什么会这样,从哪里设置才能够在登录时使用我想用的语言呢(其实答案很简单,只是现在我还没弄明白)?

后来试着修改操作系统的区域设置里的国家 为 English,重新启动, SELECT @@LANGUAGE ,返回结果还是简体中文,说明这条路走不同,也说明改操作系统的区域设置里的国家,对连接sql server的默认语言没有影响。

后来试着在企业管理器中,修改数据库的 SQL Server 属性--> 服务器设置-->默认语言 设为 English,重新启动,结果还是返回简体中文。为什么这样啊? 写到这里,我就要批评一下 sql 2000了,在SQL Server 属性--> 服务器设置-->默认语言 中,没有任何的说明,我就认为 通过设置这个选项,sql server 就按我设置的语言进行内部处理。其实改选项的作用不是我所理解,它的作用实际上是:新建用户时,默认语言如果使用defult ,那么其默认语言 等于 SQL Server 属性--> 服务器设置-->默认语言的设置值