Hi all,
I have set -YY param to 1920 .The problem is when entering some old dob like 12/12/18 dob will be inserted as 12/12/2018, but actually it should be 12/12/1918 .
Changing the code is what i supposed to do,but is there some other way to handle this so that i neednt have to edit each and every programs in my app. (having more than 100 such files) .
Also when when entering some dates like passport expiry , 12/12/18 should have to be inserted as 12/12/2018.
Please share some points on it...
Changing the code is what i supposed to do,but is there some other way to handle this so that i neednt have to edit each and every programs in my app. (having more than 100 such files) .
This is always a tricky situation!
You might consider changing the SESSION:YEAR-OFFSET attribute, that correspondents with the -yy parameter. This might be done in an ENTRY trigger of some fields, and reset in their LEAVE trigger. But I'd always make sure to reset the old value in finally block or similar. To avoid confusion.
Making sure the user does get what he want but doesn't get confused at the same time is difficult here
I would suggest that the only really unambiguous solution is to convert any field where this is an issue to 4 digit years. Anything else and you will be trying to second guess the intent of the user and risking bad data.
I would suggest that the only really unambiguous solution is to convert any field where this is an issue to 4 digit years. Anything else and you will be trying to second guess the intent of the user and risking bad data.
Any date field should be with a four digit year in display - I couldn't think of any exception. The sample data in the OP had 4 digit years and I understood the question as simplifying the data entry, not saving two characters on the screen (which was an issue on old 80*25 green screens) - but the OP might correct me when I was wrong.
And furthermore the data can be usually validated for reasonable entry with ease: A dob
I didn't get the impression that 4 year dates were displayed, but, as you say, the OP can clarify this.
My main point was to address the OPs understandable reluctance to modify a bunch of programs. If the issue is that the programs only display 2 digit years, then I don't think one can get around the need to modify them because any kind of global assumption is likely to lead to errors and the visual feedback should at least keep careful operators from making unintentional mistakes.
I certainly agree that there are many cases where on can apply meaningful validation logic. Not only can one assume that the DoB is before today, but values which indicate ages in excess of some limit should probably trigger a warning at least ... and the limit probably depends on the application.
I didn't get the impression that 4 year dates were displayed, but, as you say, the OP can clarify this.
I'm pretty sure that his fields were format 99.99.9999. When was the last time you tried to
DISPLAY 12/12/1918 FORMAT "99.99.99".
with -yy set to 1920? For the 21 years that I'm using Progress this returns a warning and a display of ????????
... and the limit probably depends on the application.
One can be even more precise than that - depending on the usecase in the same application. A DoB of an employee should be at least - 15 years (depending on regional laws and the job, i.e. you can't become president of Germany with less than 40 years of age). A DoB of children should be between today and the DoB of the parents, etc.
I didn't read anything about problems in display, but more about getting the wrong data in the DB. No error messages with the wrong data!
And, yes, specific use case was what I meant by "application" ... obviously, different rules are going to apply for DoB and Passport Expiry, as you pointed out.
I didn't read anything about problems in display
So didn't I - so the fields must be 99.99.9999 already.