7
|
|
7 |
|
|
The LA Fox Developer Newsletter
|
|
July 1999
|
|
Y2K Support in FoxPro
(Con't from page 6)
use of ambiguous dates within code and other FoxPro files. So, where do you start?
The following set of steps provides a good framework for investigating year 2000 compliance in your applications:
Read this entire paper to fully understand the year 2000 issues associated with each version of FoxPro. Over the years, new features have been added to Visual FoxPro to make it even easier to detect and resolve year 2000 issues.
Review your application, and check the forms (screens) and reports for formatting and other issues related to dates. The first step in doing this would be to ensure that SET CENTURY is ON, if you use dates before 1900 or after 1999. If you permit entry of 2-digit years, you need to assign them to the correct century for your application. If you are using Visual FoxPro 5.0 or later, you can use the SET CENTURY TO nCentury ROLLOVER nYear syntax for date windowing if you choose to leave SET CENTURY OFF. If you are using an earlier version, you can easily write data validation code to interpret 2-digit years.
Use the Visual FoxPro 6.0 SET STRICTDATE command. When you SET STRICTDATE to 1 or 2, this command will detect ambiguous dates when you compile and run your application. Even if your application is written in FoxPro 2.x, you can compile and run the code in Visual FoxPro 6.0, make the desir€d changes and then
recompile back ifl
FoxPro
2.x.
Investigate the code directly, searching for potential issues. You
can
use the Visual FoxPro Filer utility to search for specific strings in your source files, such as
WCTOD(U,
that may cause undesired behavior.
Test your application under an actual year 2000 situation by setting the Windows® system to a twenty-first century date. When you do this, make sure to close all other applications that may be adversely impacted by the system date change. For example, Microsoft Outlook® may be configured to automatically delete e-mail messages that are older than a certain period of time. By setting your system date ahead a few years, today’s e-mail messages would now appear to be outdated. In addition, you might trigger unnecessary meeting reminders.
Correction
After you complete the investigation phase and have detected year 2000 issues, you will need to make adjustments to your applications.
The following list suggests modifications that you can make to your applications. The remainder of this document describes these modifications in more detail.
Resolve ambiguous dates that are hard-coded in source code. These are dates affected by SET CENTURY and SET DATE.
|
Ensure that SET CENTURY is ON, and use 4-digit year
entry if
you want to use dates before 1900 or after 1999. This may require some minor resizing of date fields on forms and reports. However,
it
eliminates questions as to what the date input really represents. If this is not feasible, or if your application permits 2-digit dates to be entered with SET CENTURY ON, you should add validation code where data input of dates is made in order to assign 2-digit years to the desired century.
In Visual FoxPro 5.0 and later, ensure SET CENTURY TO ROLLOVER is correctly set for your application needs. This
will
vary based on the nature and context of your application.
[Note: With SET CENTURY ON, you need this setting only if you permit the entry of 2-digit years. In Visual FoxPro, ensure that the Textbox Century property is set to I (ON) to provide for entry of 4-digit dates. Otherwise you should add data validation code to the Textbox Valid and/or LostFocus events.]
In Visual FoxPro, ensure that Textbox DateFormat and Format properties are properly set for your specific application needs to avoid SET DATE issues.
In Visual EoxPro 6.0, change CTOD(
)
and CTOT(
)
functions to use enhanced Date(
)
and DATETIME(
)
functions.
Visual FoxPro 6.0 added features to help you analyze your programs and applications to determine if there is code that may provide or accept ambiguous date information. These
features
well
as other
commands and functions, make it easy to résólvé year 20b0 issues.
If you find year 2000 issues in your code, the resolution can be obvious or subtle. In general, resolution consists of changing ambiguous date entry and display formats in control design (how big a field is, how many digits are required), and using the SET CENTURY, DATE(
)
and DATETIME(
)
commands appropriately.
Take a closer look at some of the issues.
Detecting Date Issues
The “year 2000 problem” is primarily an issue of data ambiguity. Any program that uses or accepts only 2 digits to represent the year may result in unintended application behavior. There are many ways to handle this issue; some solutions are simple.
As you begin looking for problems
in
your applications, you need to be aware of the product areas that are affected by dates. In order to do this, you need to understand how dates are stored in FoxPro.
Dates Stored in Tables
For most applications, dates are stored in date fields. The good news is that date fields always store full 4-digit year precision, so there is no ambiguity in a date contained in a Date (or
|
|
Page
7
|
|
|
7 |
|