Re: Y2K query - Forms 3.0
Date: 1998/04/29
Message-ID: <3547526d.2614170007_at_news.brookes.ac.uk>#1/1
[Quoted] On 29 Apr 1998 13:09:18 GMT, Christian Mondrup <reccmo_at_sc03.sctp.dk> wrote:
>Eddie Fung <iggster_at_netspace.net.au> wrote:
>: We are Y2K repairing a Forms 3.0 application and have date fields
>: which are using DD/MM/YY format masks. When we have date fields of
>: 20nn on the database they appear as DD/MM/nn on the screen but they
>: (the screen fields) seem to be containing 19nn rather than 20nn
>: despite the fact that they are in the 21st rather than 20th century.
>: It would appear that Forms 3.0 is 'defaulting' the century.
>: Has anyone else out there come across this and if so what did they do
>: (other than expanding the field to use a YYYY format) ?
>
>Years ago someone who's name I don't remember posted some code that I used
>for this procedure:
>
> DEFINE PROCEDURE
>
> NAME = fix_century
<snip>
This won't help.
What happens is:
user enters 9 character string
[Quoted] 9 character string converted to a date. (20th century)
date processed (to 21st century)
date put back in field, converting to 9 characters in process.
century lost :-(
So the only fixes are:
use an 11 character date field.
use the RR format
write your own on-insert, on-update triggers.
Note that only the first of these allows the *user* to decide what the century should be. The other two run the risk of getting it wrong.
-- Tommy Wareing MIS Group Learning Resources Oxford Brookes University 01865 483389Received on Wed Apr 29 1998 - 00:00:00 CEST