using sco , pro4 versions 5.107 abd 4.532.
In any @SF,when in CHANGE MODE , if a DISPLAY-CODE of DATE4 is entered, SPECIAL CHECK changes to DATE. THis happens even when DATE4 was the already in SPECIAL-CHECK.
The above occurs even when the DISPLAY-CODE and SPECIAL CHECK are set to DATE4 in 'Global Dictionary Maintenence' [the @FVARDEF file].
Has anyone else noticed this?
Rob
Click the link below to see the new game I'm developing!
DATE4 bug?
Started by
Rob Fantini
, Dec 16 1999 11:04 AM
7 replies to this topic
#3
Rob Fantini
-
- Members
-
- 291 posts
ProIV Guru
- Gender:Male
- Location:Haverhill, United States
Posted 16 December 1999 - 06:07 PM
I tried here using 1.0.7.
Did you try entering 'DATE4' at 'DISPLAY-CODE'?
Just hitting enter at a DATE4 already there or using ADD mode does not cause the problem to occur.
Did you try entering 'DATE4' at 'DISPLAY-CODE'?
Just hitting enter at a DATE4 already there or using ADD mode does not cause the problem to occur.
#4
James Lolley
-
- Members
-
- 13 posts
Member
- Gender:Male
- Location:Guelph, Canada
Posted 16 December 1999 - 06:30 PM
Ok...if use a scratch variable or an existing file variable that does not have date4 assigned, then yes, if you enter date4 as the display code, the special check defaults to date. But if you change the special check to date4, it stays that way even when you go back in in change mode. Seems to me to be a minor bug since it doesn't affect existing functions.
#5
Chris Pepper
-
- Members
-
- 369 posts
ProIV Guru
- Gender:Male
- Location:United Kingdom
Posted 16 December 1999 - 06:56 PM
It's always done that. It's more irritating for me working in 3.09 as DATE is not Y2K compliant and I need to get all our programmers to use GDTVAL which is my Y2K compliant version! If they change a variable name or change it to DATE4 it resets to the DATE SC!
#6
Rob Fantini
-
- Members
-
- 291 posts
ProIV Guru
- Gender:Male
- Location:Haverhill, United States
Posted 16 December 1999 - 07:57 PM
What I ran into was an old a/p pgm which had DATE as the Display Code. Months ago I changed it to DATE4. When I made the change I had neglected to make sure the SC was set back to DATE4.
This week when our a/p dept ran an aging,there were invoices due to be paid in 01/05/1900.
So I made sure to be in at 4:00am to verify that all my programs did not have this defect. Using the file bootstrap definations I changed all occurances of DATE to DATE4 in my @LS's & regenned.
It is a simple bug with a simple fix.
The purpose of a forum like this should not be to show how stupid we are for not knowing simple solutions, but to provide information which may be useful to others.
There is a high probability that other code in the world will be broken thanks to this bug.
This week when our a/p dept ran an aging,there were invoices due to be paid in 01/05/1900.
So I made sure to be in at 4:00am to verify that all my programs did not have this defect. Using the file bootstrap definations I changed all occurances of DATE to DATE4 in my @LS's & regenned.
It is a simple bug with a simple fix.
The purpose of a forum like this should not be to show how stupid we are for not knowing simple solutions, but to provide information which may be useful to others.
There is a high probability that other code in the world will be broken thanks to this bug.
#7
Guest_Trev_*
Guest_Trev_*
-
- Guests
Posted 17 December 1999 - 03:48 PM
Setting the unix environment variable DATE_SC_50=Y and CDATE_50=Y will ensure that even if DATE s/c is used (or users forget to put in the century) the correct century will be used. These also work on NT, but I do not know about other version.
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
Click the link below to see the new game I'm developing!
