Fair comment. Something we didn't need to worry about so much before.

>I've seen users really screw up a 4 digit year date. How many records are in databases now with {10/01/9899} Simple keying error but will that one get lost in an aging? We better have something in place reall quick that will allow users to "Check & Verify"
>
>__Stephen
>
>>Hi to you John,
>>Still pretty busy over here. Could use some extra talent. Could've used Dragan here, :-)
>>And thanks for your support on this one.
>>
>>The Y2K issue will be, thankfully, over soon now. We're not complacent here, but don't anticipate any major problems.
>>
>>Dave
>>
>>
>>>Hiya Davy!
>>>
>>>Long time no see! And I agree with your post entirely.
>>>
>>>
>>>>FWIW, I'm with you. I, and my users in general like CENTURY OFF!
>>>>Bet you that within a few months of the start of next year all the users in the world will be starting to scream at us to get the annoying and redundant "20" out of the date field (except for birthdays) - LOL
>>>>And we'll all be back to where we were 10 years ago.
>>>>And all the stationery that's just been converted to __/__/_ _ _ _ will be changed to __/__/20_ _
>>>>
>>>>
>>>>>Why not? If you have SET CENTURY TO nCentury ROLLOVER nRolloverYear then an 8 character date field respects the right century. In fact, it's easier on the user to enter 01/01/01 for Jan 1, 2001 AS LONG AS the application can always determine the proper century.
>>>>>
>>>>>>I had allways used SET CENTURY ON myself, but I guess that someone would have set it OFF to cram more controls in a form, given the date control would take less space. Not a good solution, IMHO.
>>>>>>
>>>>>>>I am doing some y2k sniffing on a third party product and have come across several set century off commands? Why would someone use this command? I know their has to be a reason.