AD2 2001 Toolkit for Rapid Database Application Development with Clipper and Zachary |
 |
|
|
 |
|
|
|
|
Is Zachary Y2K Compliant? Yes! But it’s not that simple... See Also the Oasis DBF Y2K Document Within Zachary (ZACH1.EXE and ZACH2.EXE) there are only two date calculations (zBuild() returns a generation/version number and date, and _ZYEAR returns the generation year), and they use a 4-digit year; therefore, Zachary can be considered Y2K Compliant. However, older Zachary versions will improperly generate code for some B-type child procedures where SET CENTURY ON has been set to Yes and a parent linking field is a date field. While this is not actually a Y2K problem, it may become apparent when the century setting is used to resolve a Y2K issue. The problem was corrected in version 2001 (Rev. a). There is no assurance that applications generated with Zachary (or any CA-Clipper application, for that matter) will be Y2K compliant. Technically, Clipper is not Y2K compliant. It is not certified by CA as compliant, but to our knowledge, only one Clipper function has been shown faulty in a Y2K envieronment. (Details follow; and this one function probably does not occur in your code.) On the positive side, date fields in Clipper dbfs are stored with a full 4-digit year. Clipper date calculations (using actual date fields or date-type variables) are based on the 4-digit years, so they should be okay. The danger is data input/edit... where this may have been programmed as a 2-digit year. These 2-digit years are converted by Clipper to 4-digits, and by default assume a 19xx date. Clipper allows for the SET EPOCH TO command which establishes a different 100-year span for data entry/edit in 2-digit date fields. So, one concern is: Has the SET EPOCH command been used? In Zachary 2.1 and later, the SET EPOCH is established at the Application F3 Options window. The easiest solution, of course, is that all data entry is done with 4-digit years. This, too, can be set by Clipper command and in Zachary through an Application level F3 Options window setting. Another danger is misuse of data type, where dates might have been stored in a numeric or character field, and some kind of calculations might have been made. You’ll want to check that as well! Clipper Y2K Bug: LUPDATE() will not work in the new millenium. (This function is NOT used in any Zachary generated code, Zachary library code, or AD2 library code, so this is not a problem unless you have used it in your own custom code.) If you need a replacement function, check out Tom Leylan’s solution at: http://www.leylan.com/lupdate.html It will require some effort but will solve the problem nicely for Clipper applications. Blinker: Blinker 5.1 is certified Y2K compliant by its developer. This will sell some upgrades. Older versions will probably create exe programs that will work just fine, though they are not certified compliant. Unless you’re setting a demonstration date expiration with Blinker, there are really no date calculations anyway. We have no knowledge about other linkers. Clipper Tools III: If you use the Clipper Tools III function DOY(), you will need to examine how you use the function.
According to the documentation, if you don't specifically pass a date as a parameter the current date is used by default. This doesn't work after December 31, 1999. The fix is simple. Replace all instances of DOY() with DOY( DATE()
), and the problem disappears. R&R Report Writer:
Do you use R&R for reports? None of the DOS versions are listed as Y2K compliant. This may or may not be a problem for you. The only versions of R&R that are listed as compliant are the current Windows 95/98/NT versions 8.0 and 8.0a, and they must be patched with a patch available from the website.
The real problem will be in queries. What happens when you enter a two-digit year such as 2/1/01? I believe it will be interpreted as 1901. Check it out. There may also be problems with leap year calculations. Again, this may
not affect your reports. Wall Data reports on testing some older versions, "This product performs most date arithmetic correctly, but in certain situations has difficulty with ambiguous, 2-digit year logic, leap year
calculations, and date format export limitations.” Generally, you can guard against problems by using 4-digit years. You can check the If you're using Zachary you may want to use our new AD_RRW R&R Windows routines to access R&R version 8
or 9 and print using the Windows version of R&R. You'll get all of the advantages of running Windows printing (fonts, graphics, colors, and Windows printer selection), and you'll get it from your Zachary/ Clipper/ DOS
application. If you're using R&R version 8.0/8.0a, here's what R&R´s former publisher had to say:
As of Feb. 16, 1999, here's the R&R Status report: Other tools: If you use any other tools to access your data, there may be problems (particularly with dBase III+ and dbXL). Check the Oasis site for more information. Good luck as you review your Zachary applications for compliance! What’s next? The Y10K bug... 5 digit years! (Disclaimer: The above is an opinion of Richard Hamilton Associates regarding Y2K Compliance.) |
|
|
|
 |
|
Tortuga Tortoise™ |
|
Richard Hamilton Associates |
|