Re: Y2K query - Forms 3.0

rr format does not work in SQL*Forms 3.0 on date. SQL*Forms uses different version of PL/SQL engine than the database server PL/SQL engine. This may depend upon the versions.  

Tommy Wareing <p0070621_at_brookes.ac.uk> wrote in article <3547526d.2614170007_at_news.brookes.ac.uk>...
> 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
> 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