Computer People - Your thoughts on 2 digit years in databasegreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
Your thoughts please. You have an old database application running in DOS. Written in Quick Basic. (On a compliant PC) The date fields are all two digit. The program will store the number 00, 01, etc. in the field as it stands now. If, after the date rollover, you try to do a search, and you still specify the 00 as the year criteria, wouldn't the search return the correct records? I realize the implications of calling the data out into another application that handles the dates differently; but wouldn't the native searches, etc. within the original database still return the correct results? Assuming of course that you didn't have dates prior to say 50. And couldn't you still enter in two digit dates within the original application as long as they weren't called by an outside application. I'm thinking here of the small business with a custom app that doesn't use the data anywhere else. What do you think?
-- Greg Sugg (firstname.lastname@example.org), October 30, 1998
From what you say you could get by. Depends on whether or not differences between dates are used in any calculations. If all you are doing is storing and searching you will come out all right. Of course the 00 is going to sort out above 81 rather than below it as 2000 would sort out after 1989. Shucks, back up everything and set the date up and test it. Thats the only way to know for sure.
-- Paul Davis (email@example.com), October 31, 1998.
Thanks for the thought. The best I can tell, they could use the database to spit back records if the search order could be lived with and as you say, there aren't any calculations on differences in dates. Actually, for these people, it's not an issue. They've decided to let us redo the thing for them. What made me start wondering about this is the blind hope that SOME of the small biz's facing this situation, that aren't doing anything about it, might be able to fish out their records after 2000. By the way, these guys just purchased this database 3 months ago. It's written in Quick Basic, cost over $10,000, and is still non-compliant at this late date. What's more, they asked the guy point blank if it was ready for 2000. He lied and said yes. When I called him from their office, he admitted it. Go figure.
-- Greg Sugg (firstname.lastname@example.org), October 31, 1998.
I agree with Paul. Absent comparisons/calculations, retrieval will work. I would probably a window routine before displaying the data.
-- R. D..Herring (email@example.com), October 31, 1998.
QuickBasic is an ancient language, at least 10 years old. I would be suspect of anything built with a compiler of that vintage, and even more so with that amount of price. Take it back for a refund. Is the database very complex?
These days a programmer can use RAD with an IDE such as Visual Studio (Includes VB, VC++, VFP, VJ, VBS, VI, SQL, ...) to build a custom app in days, not weeks. Or if you are using less than about 100,000 records and up to 30 tables or so, an Access programmer could develop a custom app for $2 to $5k. (RAD=Rapid Application Development, IDE=Integerated Developmnent Environment).
Most Microsoft products use date windowing, however, faulty programming methods will create y2k problems even with a fully compliant development tool.
For more info on this read the June 1998 issue of Access-Office-VB Advisor, "Access, Excel, Word, Visual Basic--Year 2000 Solutions. The definitive word on how to make your desktop applications Y2K compliant.", p. 28. Check www.advisor.com but this article does not seem to be there, so go to a library.
They do have an article at http://www.advisor.com/wEdindex.nsf/623d6748edcd3f240825659500712c7e/d b2f31b0d36cc764882565b8005fa98e?OpenDocument entitled ACCESS-OFFICE-VB ADVISOR August 1998 YEAR 2000: Manage the Year 2000 Conversion Process You know you have to, but, have you converted your system yet? Here's a step-by-step guide to the process. By Sylvia Moestl
If your database is just a few tables and data screens it could be set up in a day or so with Access. If it is using FoxPro or dBase file formats and running a network of DOS machines, then VS can generate the code. The smart way to go these days is to buy off the shelf source code modules and customize it.
-- Jon (firstname.lastname@example.org), October 31, 1998.
I have never thought old data would be likely to be corrupted in a system that has Y2K problems. Temp data used for reports and such would be the most likely to be corrupted - and this is usually regenerated each time the report is run. If I ran into this problem after 1/1/00 or a fiscal year report rollover - I would just write all the data in the old year file back out to ascii data, and then rewrite the EOY report to get the EOY data. Then I would probably try to find an off the shelf app to replace what they were using, plug in the numbers and start them up again from scratch in the new year. I have had to do this kind of thing when data became corrupted and there was no provision in the software to recreate the indexes and database tables. Get the essential data, move it over to something that works - and get them started using it.
-- Paul Davis (email@example.com), November 01, 1998.
This all depends on lots we don't know.
The most important consideration is: Does the computer application make any *decisions* based on the two-digit dates? If yes, there is very probably trouble lurking (unless the original programmer employed windowing and got it right)
If not, there may be no trouble or mere annoyance value. If the date is purely recorded for subsequent print-out and human interpretation there may be no problem at all. If it's used as a sort field you may get out-of-order data (ie 00 listed chronologically "before" 99), which is a mere annoyance UNLESS that sorted data gets fed to another computer program automagically. If it's a search field there may be trouble: "all records between 6/99 and 6/00" may give only the 00 ones, or only the 99 ones, rather than both. You may be OK if you simply teat all cross-century searches as having to be done in two parts.
All is moot if you don't have source code and a competent programmer to scan it. In that case you can only guess as to consequences: number one consideration would then be "how much does it matter if this whole application stops working". If the answer is that you'd be out of business, fix or replace it NOW!
-- Nigel Arnot (firstname.lastname@example.org), November 02, 1998.