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 investi-

gating 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 automati-

cally 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 appropri-

ately.

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

(Con't, page 8)

Page 7