Re: Y2K query - Forms 3.0

From: Tommy Wareing <p0070621_at_brookes.ac.uk>
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 483389
Received on Wed Apr 29 1998 - 00:00:00 CEST

Original text of this message