6
|
|
6 |
|
|
The LA Fox Developer Newsletter
|
|
July 1999
|
|
For Microsoft FoxPro® and Microsoft Visual FoxPro® developers, the transition to the year 2000 presents a number of issues to be aware of, so that the applications you build will be fully year 2000 compliant and function with the behavior you desire after the turn of the century.
This article is meant to help you identify year 2000 issues that may be present in your applications and to suggest solutions you can provide.
It has always been easy to create year 2000 compliant applications in all versions of FoxPro. The latest versions of Visual FoxPro include enhanced language features to make this process even easier. Because FoxPro is a development language and application tool, it has always been possible for developers to create applications that will not perform as desired after the turn of the century. If you have
identified
and resolved potentially ambiguous dates during the development and testing of your applications, they may already be year 2000 compliant. If not, this paper will help you
do so.
If you have Visual FoxPro 6.0,you may also want to consult the Help files. They contain detailed
that make it even easier to identify potential year 2000 issues in your FoxPro applications.
Ambiguous Dates
As a FoxPro or Visual FoxPro developer, you probably already know that year 2000 issues are nothing more than a special case of data ambiguity. When you eliminate ambiguous references to dates, your applications will become year 2000 compliant—as long as you are using the unambiguous dates appropriately for your application. So, what do we mean by date ambiguity?
Look at a date you might have stored in a program file:
{l0/1 1/12)
Obviously, this date may have different meanings to different people:
If you are a librarian cataloging old books, you may assume that the date represents October 11, 1912.
If you are working for a US brokerage firm calculating yields on 30-year bonds, you may interpret the date as October 11, 2012.
Finally, if you are an economist in Europe forecasting economic trends, you might see this date as November 10, 2012.
|
In fact, the Date constant{1 0/11/12) could represent October 11, 1912, October 11, 2012, November 10, 1912, November 12, 1910, or November 12, 2010 depending on factors such as context and local date standards. In FoxPro and Visual FoxPro, the value represented by this ambiguous Date constant is determined by the settings of the SET CENTURY and SET DATE commands.
Because FoxPro and Visual FoxPro are developer products used for creating database applications around the world in a variety of contexts (e.g., storage of historical as well as contemporary data), developers need to understand how the rich date- related language affects their applications.
It is straightforward to determine, by reading the product documentation and entering some sample dates, how FoxPro and Visual FoxPro products resolve ambiguous dates by default For example, the FoxPro 2.6 manual states that the default for SET CENTURY is OFF and that all dates with 2-digit years are interpreted as in the 20th century (l9xx). This may be fine for the librarian above who is entering dates for antique books. However, the stockbroker might want to change SET CENTURY to ON so that full 4-digit year dates may be entered. (This is the simplest method for any application because it eliminates entry of ambiguous dates). If you permit 2-digit dates to be entered with SET CENTURY ON, you can determine how they will be interpreted if you wish to change the default behavior for the version of FoxPro you are using. By default in FoxPro 2.6, for example, 2-digit dates are interpreted with SET CENTURY ON to he in the 20th centyry (1 9xx). You can change this by writing validation or resolution cbde.
write validation or resolution code (e.g., Valid snippet, Valid event, LostFocus event, etc.) to resolve input of ambiguous dates, because FoxPro tables store the full unambiguous date.
In summary, if you can eliminate ambiguous dates from your FoxPro or Visual FoxPro application and ensure that you are handling the unambiguous dates correctly, your applications should be year 2000 ready.
How To Use This Document
Your approach to dealing with year 2000 compliance in your applications should include a two-step process of Detection and Correction. This paper is organized around these concepts and is designed to help you understand what you need to do to ensure that your applications will function in the manner your customers expect after 1999.
Detection
The most important, and perhaps most time-consuming, part of resolution is detection. You need to examine your code, including forms, reports, labels, tables, views, and query fields for unambiguous date formatting. Of course, data entry and display controls also need to be examined. You also need to check for
|
|
Page 6
|
|
|
6 |
|