Microsoft Access
(1) Access未曾考虑Windows控制面板中的短日期设置,使用了短日期输入掩码的形式,以对日期输入的位数进行控制。另外,用户的输入掩码设置可能不允许输入4位数的年,这显然存在2000年问题;同样,缺乏输入掩码设置控制的输入规则将由控制面板的设置来确定,这也关系到2000年问题。
(2)由于Access是一个数据库,所以有可能将日期/时间数据存储在文本或数字字段中,这将引发2000年问题。为避免这类问题,Access提供了日期/时间数据类型,可以支持正确的日期。
(3)使用Format函数以确保数据表单、查询结果、窗体和报表中所显示的日期都使用长日期格式,这样就保证了总是显示4位数的年。
(4) Access 2.0、95和97装载的日历控制仅能存储1900～2100年。Access 2.0也接受两位数的年,在Access 95和97中,Year的性质不像其他Access那样可以进行转换,所以,当Year的性质<1900时被认为是无效的。这样做的优点在于,使用Year的性质时就可以迫使你使用4位数的年。但是,这一控制对Value的性质不起作用,在Value的性质中可以接受两位数的年,所以,必须使用日历控制Year的性质,以防止潜在的2000年问题。
(5)如果你正在使用Access 95,可能会碰到这样一种情况:用户还不知道更新他们的OLE Automation Library,以改变对世纪的假定规则。
(6)检查所有用于日期/时间字段的有效规则,以确保它们在21世纪都能按4位年份工作。
(7)表索引可以由日期/时间字段生成,鉴别所有与这类可能存在不正确世纪信息的字段有关的潜在问题很重要。
(8)查询可以按日期/时间字段分类和排序,这些也需要检查。查询还支持可以对日期/时间字段操作的集合和函数,如Sum、Avg、Min、Max、Count、StDev、Var、First、Last等。
(9) Access中的Domain Aggregate函数可以对日期/时间字段操作,如Davg、Dcount、Dlookup、Dfirst、Dlast、Dmin、Dmax、DstDev、DstDevP、Dsum、Dvar、DvarP等。
(10)报表可以按日期/时间字段来分类和排序。
(11) Microsoft Jet数据库引擎的数据查询对象(DAO)程序接口提供LastUpdate和DateCreated属性来显示结构何时进行了修改。这些字段存储时使用的是与日期/时间一致的字段。
(12)如果在多版本的环境下使用Access,那么,还要考虑一些其他问题,如:应用程序是在两个数据库上开发的,一个"应用程序"的数据库包括所有的查询、窗体、报表、宏和模块,而另一个"数据"的数据库则存放在网络上。问题的复杂性在于应用程序的数据库安装在本地的用户机器上,并通过链接/联接表提供对网络上数据库的查询,那些用户的机器上安装了不同的Access版本,由于每个版本之间的差异,这时对世纪的确定起作用的有三种不同规则,在这种情况下几乎都会引发2000年问题。所以,如果是在一个混合版本的环境下运行,则必须了解每个版本的Access是如何解释世纪的,然后,检查应用程序的逻辑,以确保"应用程序"数据库的每个版本之间是同步的。
(13) Access通过File、Export菜单条及TransferText操作提供了输入/出功能,使用这些功能,可以指定所使用的文件和不同的选项,其中选项有"四位数的年"项,如果这一选项被关闭了,那么,所输入/出的日期将去除世纪信息。更糟的是,这一选项的默认值是关闭的。为了解决这一问题,需要确保用户永远无法看到这一用户界面,即利用将输入/出设置存储为规范的性能:应用程序的开发人员必须建立规范,并且保证"四位数年"的选项是打开的,而且应用程序在进行输入/出时必须使用所存储的规范;另外,还需要检查每一个存储的输入/出规范,以确定"四位数年"的选项是打开的。
(14)当Access的输入文本数据包含日期时,它将使用该版本认为正确的规则来识别日期/时间字段,并且将源文件MM/DD/YY中的两位数年转换为四位数。例如,当你使用Acc ess 2.0版输入一个文件,而数据包含2位数年的日期时,结果是日期数据的前面全都加上了19;如果用Access 97输入完全一样的数据,结果是日期数据前面根据源文件中2位数年的值而分别加上了19或20(滑动窗口算法);同样的问题也存在于日期的输出操作。问题的复杂性在于,输入/出文本文件时,"四位数年"选项的默认值是关闭的,这意味着,输出时所有从Access源表中出来的日期字段的世纪信息都会丢失;输入时所有源文件中的世纪信息也丢失了,而由Access使用它自己的规则来确定该年属于哪个世纪。
(15) Access的宏和模块代码中所使用的TransferText操作也潜藏着2000年问题,当使用该操作输出文本数据时,所有的世纪信息都置为20世纪,即使当源文本文件中是四位数年。这是因为如果没有指定已命名并存储的"四位数年"选项打开的输入/出规范,那么,数据的世纪信息将会改变。Access 2.0没有使用Windows控制面板中的短日期设置,所以,这时即使将短日期设置为显示四位数年,将只会输出两位数年。Access 95和97则以另一种方式处理,它们都采用控制面板中的短日期设置,在这种情况下,当计算机采用短日期设置显示四位数年,用TransferText将输出四位数年。
Microsoft Excel
(1) Excel将1900年当作闰年(实际上不是),这可能是为了与Lotus 1-2-3兼容,因为后者就错误地将1900当作是闰年。
(2) Excel中最普遍的格式是由Windows的控制面板定义的短日期格式,这种格式在显示四位数年时是不可靠的。
(3) Excel 5.0、Excel 95 7.0版、Excel 97 8.0版在两位数年时用于假定世纪的规则是不一样的,在不同版本的Excel共存的环境中使用共享日期将会出现问题。
(4)如果记录下了一个包括日期的宏,那么,这个宏将只能按照Windows控制面板中短日期信息记录下日期,这将导致宏在回放时只有两位数年。
(5)如果使用Format函数来规定日期格式为诸如"Dec 98",当2001年到来时这种规定将提供错误的日期。
(6) Excel支持VBA,而VBA使用OLEAUT32.DLL来确定两位数年的世纪,由于Excel不使用OLE Automation库,这可能引起在Excel和VBA之间的两位数年不匹配,所以,在此类应用中最好采用四位数年。
|