|
您的位置：学院
>> 编程开发 >>
PowerBuilder >> 关于PB应用程序的2000年问题
|
关于PB应用程序的2000年问题
|
---- 1． PB应用程序有2000问题
PB是我国近年来开发C/S应用程序使用最多的工具之一，包括相当多的大型应用系统，因此，清理2000年问题PB应用程序是重点。用PB开发的应用程序有没有2000年问题首先要看PB本身有没有2000年问题？按Sybase提供的资料，PB5.0.04，PB6.0没有2000年问题（certified, compliant），换言之，PB5.0 及以前的版本有2000年问题。前几年用PB5.0开发的应用程序必须进行升级或用其它程序替代。可以使用PB5.0的升级版PB5.0.04，或用PB6.0 及以上的版本升级原有的软件。
---- 那么，用PB5.0.04，PB6.0 升级或开发的应用程序就没有2000年问题了？回答同样是否。问题不在PB本身，而在开发人员，因为PB有个隐含的内部世纪日期规则和有个长短日期的表示方法，而以往的应用程序日期的年份一般都是取2位。如果使用2位年就很容易出错，可以造成2000年问题。
---- 本文根据Sybase的资料分析和讨论PB应用程序由于2位年可能造成程序逻辑和日期显示的2000年问题。
---- 2. 2位年是造成PB应用程序2000年问题的主要原因
---- 由于思维的习惯，无能是开发人员还是用户都喜欢用2位年份，并且PB的缺省年份是2位，开发人员使用2位年份便理所当然。为了识别这2位年份属于哪个世纪，PB设计了一个隐含的世纪识别规则。可是开发人员在使用2位年份的时候常不能全部顾及区分世纪，不能正确运用PB的隐含世纪规则，于是造成PB应用程序的2000年问题。PB的隐含世纪规则是：当2位年份是50-99时，PB认为是19xx年，当2位年份是0-49时，PB认为是20xx年。
---- 3．可能出现2000年问题的方面
---- 可以从5个角度考察PB应用程序可能出现2000年问题的方面。
---- 缺省的2位年日期格式问题
---- PB日期数据类型是4位年，包括数据表内缺省定义的日期数据类型。但是PB在各种场合都使用缺省的2位年日期格式，包括Window 控件，DataWindow的列，计算列及图形等。为了避免2000年问题的发生，我们不应直接使用缺省日期格式。开发人员应当手工全部将2位年调整为4位年。下面分别说明：
---- Window控件的缺省日期格式年份是2位（mm/dd/yy），例如EditMask, 其Mask 若选Type为date,
它的属性便是00/00/00。为保证4位年份，必须手工将Mask的日期置为4位年份，例如：yyyy/mm/dd，而为 0000/00/00。
---- DataWindow的列和计算列的日期采用的是short date格式（mm/dd/yy）。在DateWindow日期列的format中，缺省日期格式是[general]，[general]的格式是对应这一列的数据类型的。必须手工将其修改为4位的long date格式，即yyyy/mm/dd, 可以用test来测试更改是否成功。
---- 在有图形的DataWindow中，
日期的缺省格式也是[general]，也就是00/00/00形式。如果取X轴为日期轴，最为简单的方法是，在data 页的category 栏中用string()函数转换，如下： string( bonus_date,"yyyy/mm/dd")
---- 其中bonus_date是数据表的日期字段，可以使X轴的日期刻度为4位年。这个方法比较简单有效，因为PB在图形部分对日期format的更改操作不理想。
---- 日期字符串函数问题
---- date()是开发人员最常用的日期字符串函数，
Date（date_string）
---- 其中，date_string
是日期字符串。在使用date_string字符串时一定要清楚这个字符串日期是落在哪个世纪。如果是使用是2位年份表示日期，PB会根据其内部隐含世纪规则自动地判断是那个世纪。例如，如果开发人员心目中某个员工的出生日期是“1949/12/31”，那么应该写成：
Date（“1949/12/31”）
---- 如果写成：
Date(“49/12/31”)
---- 那么PB认为是“2049/12/31”，相差100年，两个不同世纪。
Date()函数另外一个用途时用来判断某个日期字符串是否有效，如果是无效日期，PB设计的Date()函数返回值是“1900-01-01”。“1900-01-01”是个真实日期，不注意正确使用这个返回值可以出现程序的逻辑错误。例如尽管"1999/2/29"这个日期不存在，但是下述程序的反馈是“ok”：
if isdate(string(date("1999/02/29"))) then
messagebox("response","ok")
else
messagebox("response","not ok")
end if
---- 因此要特别注意无效日期的返回判断。
---- 显示日期的string()函数问题
---- Sting() 函数是一个很有用的显示Window, DataWindow
或Rreport上的日期的函数。但是String()
函数与日期连用时要注意使用第二个说明日期格式的参数。第二个参数未说明的话，PB则使用 short date 格式， 也就是年份是2位。例如下面的用法年份将是2位：
String(today())
---- 因此应当设定String()的第二个参数，例如作如下说明：
String(Today(), "yyyy/mm/dd")
---- 世纪表达问题
---- PB提供了若干计算日期的函数，如year,
relativedate,等。由于我们处于两个世纪之交的时期，世纪表达就变得突出。世纪的表达用代码比较安全，可以避免世纪错误，例如要表达当前世纪用下述方法较好：
Left(String(Year(Today())), 2)
---- 不要用“19”
来表示当前的世纪。因为当时钟进入21世纪时，当前世纪是“20”了。不规范的世纪表达方法也是出现2000年问题的原因。
---- 日期数据的录入问题
----
在DataWindow中如果有容许用户输入2位年份的话，那么出现2000年问题的可能性很大。如果开发人员用GetItemDate（）函数提取一个2位年的输入日期，PB即使用它隐含世纪判断规则，将输入日期转换为相应世纪的4位年份日期。例如用户输入的员工出生日期是45/10/01，则GetItemDate（）函数会将其转换为2045/10/01/，而不是1945/10/01。
---- GetText（）函数从DataWindow
返回的是日期字符串，形式同用户的输入日期，如45/10/01。当使用2位年的输入方法时，开发人员必须记住这2位年是那一个世纪。如果再由此进行日期的计算或比较，哪个世纪必须明确，否则PB将用它的隐含世纪规则转换日期。
SingleLineEdit和EditMask控件也有类似的问题。EditMask的format属性缺省是2位年。如果EditMask控件的mask属性用缺省的2位年份格式，则返回的日期是2位年。EditMask控件有一个函数GetData（），如果mask属性是2位年，那么其返回的日期也按PB自己的隐含世纪规则进行。下面是使用4位年日期的例子，其中em_date
是EditMask，sle_date 是SingleLineEdit。
date d
em_date.GetData(d)
sle_date.Text = String(d, "yyyy/mm/dd")
---- 4. 关于short date 和long date
---- short date 和 long
date源自Windows控制面板的区域设置，打开区域设置可以看到日期的这两种设置。由于PB的缺省日期取自Windows 的short date，因此可以用手工在控制面板中将区域设置中的 short date 改为
yyyy/mm/dd，但是PB中的缺省日期并不自动更改，例如，需要把EditMask的日期格式需要更改为[date]International。也有人建议使用PB的RegistryGet() 和RegisterSet()函数更改操作Windows 的注册表（HKEY_CURRENT_USER\Control Panel\International），重新定义short
date，这种方法不但操作复杂，而且不能替代每一处日期格式的检查，在网络应用环境下难以管理，因此不值得提倡。最安全和最可靠的方法是不要更动Windows的shortd date和 long date的设置，把重点放在与日期有关的域格式，日期的输入输出，函数等的运用上。
---- 5． 结论
由上讨论可以看到，PB应用程序的2000年问题主要产生于使用2位年份，包括用2位年份显示日期，容许用户输入2位年份，和用2位年份操作日期字符串。PB的1900-01-01的无效日期返回值也是造成日期逻辑判断错误的重要原因。因此如果开发人员遵循下述规则，则PB应用程序的2000年问题可以避免：
使用PB的扩充属性，所有显示和输入日期格式都设置为4位年
用String()函数操作日期时，要设第二个参数为4位年
在确定日期是否为有效日期时，注意1900-01-01
|
|
|
产品库推荐 |
|
还没人留言，抢个先，哈哈!
