| Microsoft Year 2000 Readiness Disclosure
& Resource Center |
|
|
|
| Preparing Office Solutions for the Year
2000 |
|
Addressing
Programmatic Date Manipulation
Any
application that uses dates is likely to have procedural code that
interrogates and manipulates date values. This is often done with
string variables, especially in 16-bit programs that lack a
dedicated date type in the programming language. Everywhere that
such procedural code works with a date is a potential problem.
Program logic needs to be examined and tested to ensure that the
century part of the date is correctly initialized and maintained.
Diagnose and Fix Inter-Application Communication
If you
are working with a solution that needs to communicate between
desktop applications, you have to examine your logic and procedures
to ensure that date data passed between applications is correct. For
example, you may have routines that use the Windows Clipboard to
pass data between Microsoft Word and Microsoft Access. In such a
case, the Copy operation to transfer a date will grab the text
representation of the date, and depending on the format of the date,
it may miss the century information.
Additionally, you may be using OLE or Dynamic Data Exchange
(DDE) to pass data. In either case, century information can be lost
from dates, causing Year 2000 problems.
These
examples illustrate how inter-application communication can cause
problems. Additionally, the simple act of a user using the
Copy/Paste commands to move dates from one application to another
can be problematic. For example, if a date is displayed in an
Microsoft Access form as "12/31/33", when it is copied to the
clipboard it is converted to straight text and the century
information is lost--an obvious Year 2000 compliance problem.
You can
solve this problem in integrated applications by using Automation to
communicate between programs and using properties and methods that
support specific date data types (such as Date or Variant) instead
of the clipboard.
Diagnose and Fix SQL Strings
If your
application uses database functionality, there's a good chance you
are using Microsoft Access or Data Access Objects (DAO) to use the
Microsoft Jet database engine, or an ODBC backend such as Microsoft
SQL Server. In these cases, SQL is used to define the operating
parameters of queries.
So as
the first step, you must identify all SQL strings in your
application. The next step is to ensure that the SQL contains no
expression code that could cause Year 2000 problems. This is most
commonly seen when expressions like Left and Right are used to break
a date into its component parts. For example, the following SQL
string is not Year 2000 compliant because it removes the century
data from a date:
SELECT
DISTINCTROW Orders.[Order ID], Orders.[Customer ID], Orders.[Order
Date]
FROM Orders
WHERE ((Right([Order Date],2)>92));
To solve
this problem you can either using fully qualified date values with
4-digit years as in:
SELECT
DISTINCTROW Orders.[Order ID], Orders.[Customer ID], Orders.[Order
Date]
FROM Orders
WHERE [Order Date] > #12/31/1992#));
You can
also use built-in date manipulation functions:
SELECT
DISTINCTROW Orders.[Order ID], Orders.[Customer ID], Orders.[Order
Date]
FROM Orders
WHERE DatePart("yyyy", [Order Date]) >
1992);
Diagnose and Fix Object Property Values
Properties exist in modern development environments to define
a specific object's behavior. You can set properties on a variety of
objects that may be date related. Most properties allow the input of
either an expression or a literal value. For example in an Microsoft
Access form control's DefaultValue property, you specify a value to
be placed in the control if one is not specified by the user. Two
types of values can be placed in such a property:
| Type |
Description |
| Literal values
|
Literal Values are
strings of text that are to be taken literally. For example,
if the DefaultValue property contains 01/01/90, a string of
"01/01/90" would be placed in the control. |
| Expressions |
Expressions are
strings that are evaluated by the program, and a value is
returned based on the expression. For example, in a control's
DefaultValue property you could enter the value Now, which
would cause the form to run the Now() function and place its
results in the field. This is an example of an expression
calling an intrinsic date function.
| Table 2 Literal values and
expressions
To
ensure that property values are Year 2000 compliant, you must
examine each to see if the literal value or expression could cause a
non-conformant date to be stored or acted upon.
Diagnose and Correct Macro Code
Custom
solutions are often based on the macros you design. Examine all
macro routines to detect:
- Actions and action arguments that work with date data.
- Expressions in arguments of conditions that could cause Year
2000 data anomalies.
- Product-specific date functionality that imports or exports
data. For example, in Microsoft Access, the use of
TransferDatabase, TransferText, or TransferSpreadsheet actions
should be examined.
|
