Special Edition Using Visual FoxPro 6
Every day you read in the newspaper or a magazine some nightmarish projection of how unprepared the world's computer systems are for the coming of the year 2000. You hear news such as over half of the nation's largest corporations have not even completed their assessment of the Year 2000 (Y2K) problem. Only a third of these companies have started converting their systems to be Y2K compliant. The U.S. government appears to be just as far from compliance. You also occasionally hear dismissals of the entire problem as hyperbole or an imagined concern. Some people say that the problem is exaggerated by software vendors in an effort to sell Y2K software and development services.
At the risk of sounding alarmist, folks, 1998 is almost over! There is just one year left to modify billions of lines of legacy code and legacy hardware to Y2K compliance. Systems critical to our civilization, such as air traffic control, power grid control computers, transportation systems, traffic signals, financial computing systems, and so forth are far from being Y2K compliant. Of course, the Internet is also vulnerable because it relies on millions of computers, some of which might not be Y2K compliant. But that is the least of your worries, because you might have no electricity, water, gas, or telephone service, and your ATM and credit cards may be rejected. If any of that occurs, Internet problems drop rapidly down the priority list.
What is the Y2K issue? It all stems from the fact that software designers wanted to make it easier for the user to enter a date, so they decided to design their software so that the user would only have to enter two characters to input a year. This saved keystrokes as well as expensive memory resources. Users were happy and bought more "easy-to-use" software. None of us ever anticipated that the same software and hardware systems would still be used 20 to 30 years later. The problem was exacerbated because the traditional two-digit year data entry became a standard for all new systems developed. The use of a date with a two-digit year for data entry, storage, and retrieval is the basis for the Y2K issue.
Y2K compliance is not just a mainframe computer problem. Many microcomputer software packages use dates with a two-digit year. About 90 percent of the personal computers (PCs) made before 1997, and about 50 percent of those made in 1997, are said not to be Y2K compliant. The most common problem with these PCs is with the BIOS (Basic Input/Output System) chip that is part of the PC hardware system. The BIOS contains code that boots the PC. The computer also contains a clock chip that supplies the time and date to the BIOS. When you set the time and date from your operating system, the BIOS writes it to the clock chip. It even writes a four-digit year to the clock chip memory. Therefore, there is no problem setting the clock to the year 2000. However, the clock chip used in most PCs increments only the last two digits of the year. If the PC is operating when the clock strikes midnight on New Year's Eve of 1999, there is no problem because the real-time clock in the computer handles the time correctly and the clock chip is set correctly. However, if you shut down your PC before midnight on that date, the clock chip increments only the last two digits of the year and the date goes from 1999 to 1900. On New Year's Day, 2000, when you boot up your computer, your PC's clock is set to January 4, 1980. Why is it set to January 4, 1980? When your computer boots up, MS-DOS does not recognize January 1, 1900. MS-DOS is programmed to change an unrecognizable date to January 4, 1980. You probably will not even encounter this problem because Microsoft has incorporated logic in Windows NT 4.0, Windows 98, and Windows NT 5.0 to automatically change a 1900 date to 2000 when the PC boots up. Microsoft also provides a patch to fix the BIOS problem for Windows NT 3.51 (sp5) and Windows 95. This resolves the Y2K issue for most PCs. However, there exist a few PCs that have BIOS that Microsoft's solution will not resolve. These PCs simply do not accept a 21st-Century year. Your Visual FoxPro application might be completely Y2K compliant, but unless your customer's PCs are Y2K compliant, your application might not work properly. And guess whose problem it becomes.
On September 9, 1998, a U.S. House of Representatives panel gave
grades to various government agencies regarding their Y2K compliance
prior to that date. Most agencies received a poor grade, as indicated
in Table 24.1.
| Social Security Agency | |
| National Science Foundation | |
| Small Business Administration | |
| Department of Defense | |
| Transportation Department | |
| Justice Department | |
| Dept. of Health and Human Services | |
| Department of Energy | |
| State Department | |
| Dept. of Education | |
| Agency for International Development |
You might think that the United States Government is not prepared for the next millennium. The United States, however, is better prepared than most other countries, as shown in Figure 24.1. This chart shows the percentage of organizations in various countries that are expected to be Y2K compliant by January 1, 2000.
When dBASE III was designed, it was decided that the date stored in the tables (.DBF) and internally would contain a full four-digit year. The SET CENTURY ON/OFF command was also incorporated. Many systems such as Lotus 1-2-3, Access 95, and Excel 95 normally store a two-digit year. Because FoxPro is a clone of dBASE III, FoxPro also utilizes a four-digit year. As a result, FoxPro 2.6 is considered to be almost Y2K compliant.
All versions of FoxPro and Visual FoxPro treat a date as a numeric value representing the number of days since a fixed date. This number is stored in tables, variables, and is used to perform date calculations. The century is never lost. The only problem is that applications have been developed using a date with a two-digit year to simplify data entry. Visual FoxPro 5.0a treated dates with a two-digit year as 20th-century dates.
You should always use a four-digit date to achieve Y2K compliance by specifying the SET CENTURY ON command. However, the Visual FoxPro 5.0a SET CENTURY command had other features. The full Visual FoxPro 5.0a syntax for SET CENTURY was:
SET CENTURY ON | OFF | ROLLOVER SET CENTURY ON | OFF | TO [nCentury [ROLLOVER nYear]]
The ON keyword specified that the date field would have a four-digit year (for example, 1/1/1999). The OFF keyword specified a date with a two-digit year and assumed the year to be in the 20th century (for example, 1/1/99). The optional TO [nCentury] clause specified a number from 1 to 99 designating the current century. The TO clause was only used with two-digit fields. If you omitted the nCentury number, the 20th Century was assumed. For example, if you specified SET CENTURY TO 21, the date {10/11/62} was assumed to be 10/11/2162. The ROLLOVER nYear clause specified a number from 0 to 99 designating a year. Dates with a year that was less than nYear were considered to be in the next century. Other dates were considered to be in the current century.
In the next section, you will be introduced to the enhancements to Visual FoxPro in version 6 that make it much easier to achieve Y2K compliance. But first, here are some recommendations to acquire Y2K compliance using Visual FoxPro 5.0a:
You can see that Visual FoxPro 5.0a was rather well positioned for the next century. However, the Visual FoxPro developers at Microsoft made Visual FoxPro 6 even easier for developers to create applications that are Y2K compliant, as you will see in the next section.
Year 2000 will be here soon, and software developers are rushing around trying to ensure that their applications are ready for the year 2000. Visual FoxPro developers get some welcome assistance in their Y2K risk identification effort by utilizing the new strict date type and the optional type enforcement.
The current SET CENTURY and SET DATE settings are used when Date and DateTime constants are evaluated to determine how the data is to be interpreted. Their value can be different depending on when they were compiled and what date-related settings were active at compilation time.
Visual FoxPro 6 can detect and report any occurrences of ambiguous dates during compilation and execution. For example, which century are we talking about in the following assignment?
){kind=link}
dBirthDate = {2/29/12 10:21}
I haven't a clue. Is it my mom's birthday or some date next century? The date is ambiguous. What were the settings for the SET DATE TO and SET CENTURY commands when this module was compiled? For example, what if the century changes, which it will soon? Suddenly, the date is for another century.
This is no longer a problem if you replace all the occurrences of ambiguous dates with dates conforming to strict date format. The format for a strict date is the following:
^yyyy-mm-dd[,][hh[:mm[:ss]][a|p]]
where yyyy is a four-digit unambiguous year. The caret character (^) that precedes the year denotes the strict date format. The Date and DateTime values are interpreted in a consistent YMD format. Valid Date and DateTime separators for the date are hyphens (-), forward slashes (/), periods (.), and spaces. Empty Dates and DateTimes are considered always valid. Valid empty Date and DateTime formats include {}, {--}, and {--,:} {}.
Let us rewrite the assignment in a strict date format:
dBirthDate = {^1912.2.29 10:21}
dBirthDate = {^1912-2-29 10:21}
dBirthDate = {^1912/2/29 10:21}
Now that Visual FoxPro 6 enforces strict date formats, you can recompile your applications in Visual FoxPro 6. The compiler will find all of your Y2K non-compliant code. If the compiler encounters any Date or DateTime constants that are not in the strict format or that evaluate to invalid values, Visual FoxPro 6 will generate an error.
The largest valid date in Visual FoxPro 6 is December 31, 9999 AD, or {^9999/12/31}. The smallest date that you can specify is January 1, 1 AD or {^0001/1/1}.
The new SET STRICTDATE command controls Y2K compliance enforcement:
SET STRICTDATE TO nMode
The nMode value designates how format checking is performed, according to the following values:
| Strict date format checking is turned off. This mode is Visual FoxPro 5.0a-compatible and is the default mode for runtime and ODBC drivers. When STRICTDATE is set to 0, invalid Date and DateTime constants evaluate to an empty date. | |
| All Date and DateTime constants are in the strict date format. Any Date or DateTime constant that is not in the strict format or evaluates to an invalid date generates an error, either during compilation, at runtime, or during an interactive session. For an interactive session, the default setting for nMode is 1. | |
| This option is identical to setting STRICTDATE to 1. It reports a compilation error, 2033 - CTOD and CTOT can produce incorrect results, when either the CTOD() or CTOT() function is encountered in the code. |
The CTOD() and CTOT() functions return a value that is based on the current SET DATE and SET CENTURY settings. As a result, the CTOD() and CTOT() functions are a Y2K non-compliance risk. You should use the DATE() and DATETIME() functions to create Date and DateTime constants and expressions.
Notice that the StrictDateEntry property is not controlled by the SET STRICTDATE command setting. The StrictDateEntry property remains unchanged in Visual FoxPro 6.
You can visually alter the default SET STRICTDATE setting. To do so, choose Tools, Options and click the General tab in the Options dialog (see Figure 24.2). Set the Strict Date Level using the list box in the Year 2000 Compliance group, which includes a Year 2000 Compliance drop-down list box. This list box specifies the SET STRICTDATE setting.
Figure 24.2 : The General tab of the Options dialog is where you can change the STRICTDATE setting.
| NOTE |
Reminder: If you exit the Options dialog using the OK button, the value is set for the current Visual FoxPro session. You must click on the Set As Default button to save the setting to the Windows registry for the next Visual FoxPro session. |
You can use the DATE() and DATETIME() functions to create Date or DateTime values. To support this functionality, numeric arguments have been added to the function syntax. These functions are a preferable method for creating Date and DateTime values. You do not need to use the CTOD() and CTOT() functions because they can increase the risk of Y2K non-compliance. In the following example, MyDate is assigned a Date value in both cases:
MyDate = CTOD(Date()) && Old form MyDate = Date(1) && preferred Y2K compliant form
The FDATE() function has been modified to use an optional argument to determine the time a file was last modified. You no longer have to use the character manipulation functions. For example, in Visual FoxPro 5.0, you had to write code to determine when the file was last modified. Here is the code:
){kind=link}
tLastModified = CTOT(DTOC(FDATE('MyTable.dbf')) + ' ' ;
+ FTIME('MyTable.dbf')
For Visual FoxPro 6 programs, the preceding code can be replaced with the following:
tLastModified = FDATE('MyTable.dbf', 1)
In Visual FoxPro 6, the default setting for the SET CENTURY command is ON and the Century property default is:
1 - On
In previous versions of Visual FoxPro, the default value for the SET CENTURY setting was ON and the default for the Century property was
2 - the SET CENTURY setting determines if the
century portion of the date is displayed.
In Visual FoxPro 5.0, if SET CENTURY TO was used without any argument, it was set to 19 (the 20th century). In Visual FoxPro 6, the SET CENTURY TO command sets the century to the current century. Also, in new data sessions SET CENTURY TO is initialized to the current century.
In Visual FoxPro 5.0, the default value for nYear was 0. In Visual FoxPro 6, the default value for the ROLLOVER nYear clause for the SET CENTURY command is the last two digits of the current year plus 50 years. For example, if the current year is 1999, the default value for nYear is 49 (1999+50).
© Copyright, Sams Publishing. All rights reserved.