| Microsoft Year 2000 Readiness Disclosure
& Resource Center |
|
|
|
| Preparing Office Solutions for the Year
2000 |
|
Existing
Data Assets
As
mentioned earlier, your application is not the only thing that can
be suspect. You must ensure that all data is correct and Year 2000
compliant. Data can take many forms in your applications:
- Database storage using Microsoft Access and the Microsoft Jet
database engine
- Microsoft Word documents
- Microsoft Excel documents
- Microsoft Outlook data
- Text files
- Initialization (INI) files
- System Registry entries
- Legacy formats such as xBASE, delimited and fixed length text,
CSV and WKS.
Identify all Date/Time Database Fields
If you
Microsoft Access or the Microsoft Jet database engine, it is helpful
to have a list of all date/time fields in your database. This makes
it easier to spot date usage in other parts of your application. For
example, if you have a textbox control on an Microsoft Access form
that has no InputMask, Format, or Validation Rule property settings
that identify it as date-related, you can look in your list of
date/time fields to see that the control is bound to a date/time
field. Similarly, with a Microsoft Visual Basic application, look
for the use of the data control to identify if date/time database
fields are being used.
Identify all Non-Date/Time Fields Used to Store Date Data
Often,
data import and programmatic date routines place date data in tables
in a field type other than date/time. This is most often seen in the
form of text fields that hold dates. This is a huge source of
problems because strings do not represent centuries reliably and
will most likely fail in the year 2000. To solve this problem, you
must identify all fields in your tables that are not date/time
fields, yet are used to store date data. Common formats for suspect
data are:
| Format |
Example |
| mm/dd/yy |
12/13/92 |
| mmddyy |
121392 |
| mmyy |
1298 |
| mm |
07 |
| yy |
92
| Table 3 Formats for Suspect Data
Fields
After
you have identified all text fields, take a look at the number
fields. Often date data is hidden in number fields.
Once you
have identified all non-date/time fields used to store date data,
plan the steps necessary to convert this data to date/time fields.
Before doing the actual conversion, be sure to understand what is
going to happen to dates that have only two digits storedùwill the
resulting century applied by your application be correct for your
data? You may need to create special update queries to convert the
data to the proper century.
Use Statistical Analysis to Spot Trends that Identify Suspect
Data
Another
useful technique for identifying non-date/time fields used to store
date data is to use simple statistical analysis. For all the fields
you identify as string or number, use the your database's aggregate
functions, such as Min, Max, Sum, Avg, and Var functions to return
useful statistical information about the data in those fields. For
example, a Min and Max query against a suspect field would show
whether or not the range of values falls into valid date range.
Third-Party Controls and Libraries
Many
applications make use of third-party controls or libraries. These
take the form of custom controls (*.OCX), dynamic link libraries
(*.DLL) and in Microsoft Access, library databases (*.MDA). In
Microsoft Word and Microsoft Excel solutions applications, you can
also use templates and add-ins.
If your
application uses any of these resources, you must ensure that Year
2000 issues do not exist in those components. Unfortunately, you
often do not have the source code for such resources, so you will
have to obtain certification from your vendor(s) that the components
are Year 2000 compliant.
|
