| Microsoft Year 2000 Readiness Disclosure
& Resource Center |
|
|
|
| Preparing Office Solutions for the Year
2000 |
|
Checking
Data Import/Export Routines
Many
custom solutions developed using Microsoft Office have requirements
to import and export data from other sources. For example, your
Microsoft Access or Microsoft Excel solution may use import
functionality to massage data brought in from legacy systems.
Whenever you bring data into your application from an outside
source, or export data out, the potential for Year 2000 issues
exists.
Identify Native Import/Export Issues
If you
are using built-in tools to import and export data, be sure to
examine your application's results to ensure that they are Year 2000
compliant. For example, you can use the TransferText command in
Microsoft Access to import or export text data. Or you can use
Insert, File in Microsoft Word to bring in external data that may
contain dates. In all such cases, the date data is treated as
strings and may cause century problems.
Review Programmatic (Custom) Import/Export Routines
You must
also examine your application for any place where you are using
macro or module code to import or export data. Each case needs to be
verified to ensure:
- For exports, the full four digits of the year are being
output.
- For imports, all four digits of the year are being retrieved,
or in the case where the input file has only two digit years, the
correct century is being assumed.
When
data is imported from an external text source, the potential for
bringing in dates with two-digit years exists. You must examine how
date data is being brought into your application. Are you working
with a data source that has all four digits of the year? When the
application brings the data in is the century being maintained
correctly? Similarly, when you export data for use by other
programs, you need to ensure that you are always writing out the
full four digits of the year.
Issues
also exist when using the native BASIC file routines. As you can see
from the following code example, writing dates to files these
routines can have the same problems. When you run the following
code:
Open
"C:\testd.txt" For Output As intfile
Print #intfile,
CVDate("12/13/1901")
Print #intfile,
CVDate("12/13/1991")
Print #intfile,
CVDate("12/13/2001")
Close #intfile
The
resulting file looks like this:
12/13/01
12/13/91
12/13/2001
The
century is truncated because of the Control Panel short date
settings. Additionally, customized import/export logic contained in
module code may be suspect, especially if data is being imported
from or exported to a format that cannot accept four digit years.
|
