>With the ROLLOVER feature, what is your resistance to 2-digit dates?
None, assuming that I'm using a version of VFP with ROLLOVER (I'm stuck in FPW2.6 here )

>Also, another example of where Y2K problems can exist (there are hundreds): A registration number must be generated. The 2-digits of a year is to be used somewhere within the registration number. In 1983, the programmer didn't think about the Y2K problem and just used the formula YEAR-1900 (eg. 1983-1900=83) to get the two digits. In the year 2000, that will give three digits which could cause an overflow or other problems. Hey, don't look at me. I was in high school in 1983. But in 1983, when a programmer was being pushed to get a system done, do you think he/she was really thinking about Y2K?
>
Speaking as someone who was programming in 1983 no, we weren't thinking about Y2K. We were thinking "how the h&*^ do we get this beast out the door on deadline" or if in long-term mode "they won't be using this in 10 years -- we can think up a better way next time round."

Certainly I was not developing systems on "microcomputers" that I expect to last more than 3 - 5 years. I was expecting hardware & software to evolve so that most of what I did would be redundant within that sort of timeframe. I do however have a system in dBASE III that has been running since 1984! Still running on the same XT. Needless to say, it doesn't get a lot of use... But it does it's job so there seems to be no need to change it. Actually, last time I saw the system (it's in London, I'm in Boston,MA,USA) was almost 2 years ago. It might well fail in 2000, as it does employ dates. However, after 16 years it's certainly paid for itself. I certainly didn't expect it to last that long.

So, guess I'm guilty of being a contributor to the Y2K problem. So impeach me...

Jen