DataEase, Y2K and ComputerWizard Consulting

So, 1 January 2000 came and went. Airplanes didn't fall out of the sky, the power stayed on, and civilization as we know it did not come to an end. But there are still three issues that need to be addressed with the Year 2000. Your toolkit, e.g., DataEase. Your application or database. What can ComputerWizard Consulting do for me? If your toolkit will stop working on January 1, 2000, you must replace it now—you have no choice. Even if your toolkit is Y2K-compliant, the database that you have built with it (or has been built for you) may require some changes to avoid problems   during 2000 and on into the next few years.

DataEase and Y2K Compliance

1. All versions of DataEase prior to version 4.2 for DOS will stop working on January 1, 2000. Period. Full Stop. There is no reprieve. If you are using verison 4.0, you must upgrade your copy of DataEase. While DataEase 4.2 will boot up after January 1, the system clock displayed in the lower right-hand corner will read the year as “100” and any derivations that use “current date” may miscalculate. We strongly suggest that you upgrade.
   
2. Version 5.15i or greater of DataEase for DOS is fully certified by Sapphire as Y2K compliant. (For more information, check out Sapphire’s Millennium Information Bulletin (MIB) on their website and follow the links. Please note that Sapphire requires that you register on a mailing list in order to view the current MIB.)

What about version 4.53?
In a previous MIB, Sapphire referrred to v4.53 as “partially compliant”, and said that “the product does not fully comply with the BSI Millennium Rules described in Section 2 [of the British Standards Institute’s definition of Y2K compliant]. Sapphire has no plan to provide further compliance in future.”

Since that time, however, the BSI and/or the UK government have changed their definition of Y2K compliance, and Sapphire has withdrawn the “partially compliant” statement, and now describes v4.53 as non-compliant.

Although v4.53 allows a user-settable 100-year window of dates, there is a bug in the searching algorithm that could create problems. Sapphire stated in that earlier MIB:

The 4.5xx and prior products have a limitation which prevents them from recognising ‘Wildcard’ token searches in the ‘Year’ component of a two digit Date Field which starts with a leading 0, e.g., a search for the dates 01/01/1908 or 01/01/2000 will not work. The Wildcard bug also affects match criteria in QBE/QBM/DQL—it will cause either all or no records to be retrieved. This limitation is removed in current product development code—the DataEase Versions 5.15 for DOS and 5.14 for Windows. Users of 5 Series versions prior to these are advised to contact Sapphire for a Service disk containing patch software.

(You can get all of the patches to version 5 here on this site as well, by checking out our Downloads pages.)

ComputerWizard Consulting did some testing (admittedly on a small sample). We created a table (called TestDataTable) and entered three records:

In record-entry mode, if you press Alt-F5 (Unchecked) and then enter 01/01/*1 in the TestDate field, then press the F3 (Next Record) key, the appropriate records are displayed. If you enter 01/01/?1, then DataEase will tell you that no records exist.

Similarly, the following DQL:

	for TestDataTable with TestDate = 01/01/*1 ;

		list records

			TestDate in order .

	    end .  -- main loop .

returns the two correct records, whereas this query

 	for TestDataTable with TestDate = 01/01/?1 ;

		list records

		[etc]

returns none.

A DQL with the following selection criteria:

	for TestDataTable with

	    TestDate between 01/01/*1 to 01/01/25 ;

		list records

		[etc]

lists only the two dates in the year 2000, whereas the following DQL:

	for TestDataTable with

	    TestDate between 01/01/?1 to 01/01/25 ;

		list records

		[etc]

lists all three records..

What does this mean to me?
The answer is “it depends”.

If

• You don’t need to keep track of more than 100 years of data, or
• Your auditors, management, parent company or other supervisory/regulatory bodies do not insist or require “extended” (four-figure dates), or that all software be certified as Y2K compliant, or
• You can live with the bug discussed above (or rewrite your DQLs to avoid it),

then you may not have to upgrade from v4.53 to v5.15i (or later).

On the other hand, if

• You need to keep track of more that 100 years of data, or
• All software in use must be certified as Y2K compliant by the vendor,

then you must upgrade to 5.15i or later.

Upgrading is the easy and least time-consuming part of the process.

What about DataEase for Windows? (DFW)
Again the answer is “it depends”. If you are faced with a tight deadline and large, complex database, go for the DOS/CUI option. If you have a small database, with only a half-dozen tables and reports, consider DFW as an option.

I think DFW is a wonderful product that’s made quantum leaps forward over the past couple of years. Version 5.5 is currently shipping, and it supports the extended-date field (The upgrade to 5.5 is “chargeable” upgrade—it is NOT a free patch.) However, DFW has a learning curve. It is not a simple “port” to Windows of DataEase for DOS. The Windows environment has its own tricks and you need to think a bit differently when it comes to designing forms and reports. While the forms and tables can be converted easily, and the DQLs come across nicely, all report layouts/formats have to be redone. The report writer works a quite a bit differently than the one you are used to with DataEase for DOS, and some of the “tricks” that work nicely in DEDOS don’t work at all in DFW.

It's been my experience, that as a result, that a DFW conversion requires a rethink and a rewrite of a large part of the application. It does give you an opportunity to eliminate some deadwood from the application, and to review whether or not the rules that govern your business have changed since you created the DOS verison of your database. Now that the Y2K deadline crunch is behind us, you might want to take a look (or a second look) at DFW. Demo versions (limited to 100 records per table) are available from Sapphire's web site.

Whether you upgrade your toolkit to version 5.x or not, you must analyze the database application (the collection of forms, reports, processing procedures and imports) for Y2K-related problems and determine what steps are necessary to prepare you for the year 2000 and beyond. Once the analysis is done, you need to go through the application and make whatever changes are needed, then test the application. This is the harder and possibly the most time-consuming part.

Things to look for include:

• Do I need to span or keep track of more than 100 years of information?
• Am I sorting or grouping on the built-in year() or julian() functions?
• Do I have any “manufactured” dates created by the date() function or any two-digit YearOf fields like DateOfHireYear?
• Do I have any “hard-coded” century numbers (especially 19) in any field derivations, report calculation or report formats?
• Do I need to reduce ambiguity in interpreting dates?

More than 100 years of data
Let’s say you have an employee born in 1940, and a two-digit field called RetirementYear, defined as:

	year(Date of Birth) + 65

which means that this employee will retire sometime in 2005 (or “05” if you stay with two digits). If you set the start date in DataEase’s database configuration file to 40, you can use a two-digit date to keep track of dates between 1940-2039—which covers this employee.

Now let’s say you hire a new employee, born in 1980, whose scheduled retirement date is 2045. Ooops! Now you need to keep track of dates from 1940 (birthdate of the oldest employee) to 2045 (retirement date of the newest employee). 1940-2045 is more than 100 years apart, and a two-digit year will not suffice. You will have to upgrade to a version that supports extended dates.

Sorting or grouping on year()
The built-in year() function returns a two-digit number in version 4.53. Thus:

year(03/12/58) returns 58 and
year(03/12/00) returns 00

Assuming that 00 refers to 2000, then sorting on a date field in a DQL will result in the information in 2000 (e.g., 00) coming before the information in 1958.

In v5.xx, the year function returns a four-figure number, but any DQLs that sort or group by date need to be edited and resaved before they will work properly.

Manufactured Dates
Take another look at the RetirementYear example. Remember, we defined a two-digit field as

	year(Date of Birth) + 65

The field in the table is only two-digits long. This can create problems with calculations that use the figure as a proxy for the actual date—since 00 minus 99 is a negative number! How many date fields do you have in your database which create a date using the date() function—could any of them malfunction? Do you have fields called FiscalYear? ShowYear? ModelYear? (How many digits are they?)

Or even worse, are the names of your fields cryptic—like SpEnDtY?

Hardcoded 19s or 20s
How many reports do you have with the year portion “hard-coded” (or pre-printed) on the report layout (like all those cheques you’re going to be forced to throw out)?

In one Y2K audit we performed, we found the following derivation on a data export DQL (which sent a file to a third party):

YearOfHire := jointext("19", year(DateOfHire))

This is fine, until a new employee is hired in January 2000—and the insurance carrier is informed that a new employee joined the firm in January 1900!

Date Ambiguity
Can you tell easily whether 01/01/02 is 2002 or 1902? If not, you will need to upgrade to a version that supports the extended date format—no ifs, ands or buts about it!

1. If you are an experienced DataEase developer, we can sell you a copy of Increase V and a copy of DataEase v5.x—both of which you will need in order to use the free Millennium/EMU audit tool that you can download from Trainease. (The audit tool is a DataEase 5.xx database with a customized series of reports to assist you in auditing the database. You need Increase to extract the data from your application. The data is imported into the Millennium/EMU audit tool database). Then you can audit the database yourself and fix whatever needs fixing.
2. We can perform the audit for you and provide you with the results, including a detailed workbook indicating all of the areas that require modification and testing—which you can then do yourself.
3. We can do the audit, 5.xx upgrade and the Y2K conversion for you.