>>Can you argue that typing 4 digits is as fast as typing 2 digits? No. Therefore there is a benefit to typing 2 digits. Now, the decision process involves weighing the different benefits/problems. Given just one benefit for 2 digits (speed), one can decide that it is a better choice depending on how he weighs this benefit.
>
>PMFJI, but the cost/benefit would be a wrong date because managemet wants to sacrifice less than 1 second of data entry time per date versus assuring an unabiguous date (assuming you have quite competent/professional heads-down data entry staff). The only way you can be assured the year is correct is if you do not have any dates fall outside of a 100 year window. Can that be guaranteed?
>Now on the hopefully helpful side -- you could make an assumption in your class that the century is that of the system date if only 2-digits are entered for the year and maybe combine this with the ROLLOVER feature.
>
>Also, is it a requirement that the year be the FIRST part of the date? If you could at least get agreement to put the year at the end, 99% of your problem is resolved. You could enable the SelectOnEntry then not worry about an entry of 010299 turning into 01029998 or some other such bizarre year.

What does PMFJI mean?

100 year window can be virtually guaranteed. I have already thought of this. If things go ahead with a 2 digit year, a key-combination will change the current date entry field to 4 digits until focus is lost. But this would probably be unnecessary. Also, I am right down the hall. I can change data if need be.

The ROLLOVER feature is there to assume the correct century. It works. It is just the fact that the field shows 4 digit years when you re-enter.

The YMD format has always been how we do things. I forget if I ever even asked why. I don't know why. I am planning on discussing this...

Joe