Return To Index
Return To Index
So it's a no-win situation for the IT industry. However, we feel that prevention has to be better than cure, and are setting up to offer the help users need.
As background, the dating problem originates from the well meant practice of minimising effort by using just two digits for the year, i.e. dd/mm/yy format.(mm/dd/yy in the USA). So the century was not defined, and there is an obvious ambiguity as we change centuries.
A fairly general view is that entering the full year number is going to be necessary (dd/mm/yyyy) ; and to confuse things further there are suggestions to remove the differences between USA and UK by having a new international format of yyyy/mm/dd. (About time this was standardised - Ed)
Below, we give a clue to the problems in a particular area, that of Microsoft Access; probably the leading Database software. Microsoft is saying that versions in Office 97 will allow 2 digit date entry over a period spanning year 2000. That is good, but Office 97 will only run on a 32 bit operating system; so as well as buying the updated Office 97, users will have to update from say Windows 3.11 to Windows 95 or Windows NT. Then they will also need more memory, and, particularly with Windows 95, could have hardware incompatibility problems.
We thought it might be instructive to see what was involved in updating the dating method for an existing application.
What to do for a simple Sales Order Processing system using MS Office Pro 4.3, Access database.
Access version 2.00 will interpret 20/3/00 as 20th March 1900, so it is necessary to enter dates with a 4 digit year i.e. 20/3/2000 for 20th March 2000.
Just to confuse matters, Excel spreadsheet, in the same Office package will interpret 20/3/00 as 20th March 2000, but 20/3/20 as 20th March 1920!
Suppose we have tables for Jobs, Sub-Orders, Invoices etc. All these have a date field with a format dd/mm/yy, so we have to change these to a dd/mm/yyyy format and ensure that at data entry the full year number is entered. So as well as changing formats, we have to set up input masks and validation warnings.
The first step is a "Software Audit". This will establish the scale of the problem.
The second step is a programme for modification and/or procurement of new software. This needs to be very detailed, and must take into account operational requirements of the user.
Finally, implement and test your solution.
Before starting, make a back-up copy of the complete database. Just in case everything fouls up and you corrupt your data. Call this database "BU"
For each table in the database:
Change the date field format to dd/mm/yyyy. This is not a standard format, so it must be created as a custom format.
For each form which feeds off or allows input to that table:
Set the format to the custom dd/mm/yyyy.
Create a custom input mask. - 99/99/0000;0;
Add a validation warning message.
These are all done in the properties for the date entry box in the design view of the form.
This should become your working database for the future, call this database "Main".
However we need to test it; and this will create invalid data. So make a copy of the Main database, and use this to test input on all forms and all tables. Call this database something obvious such as "Test". Try entering data for a range of dates, say from 1990 through to 2020.
If there are problems, probably through minor typing errors, amend the properties of "Main" , recopy to "Test" and try again.
Of course there may be Macros, Reports and possibly Procedures. These all need to be checked, modified and tested as well.
So, even with a simple application, there can be quite a lot of work to do.
Contact for further information:
