Re: Y2K for NT and Oracle

Thank you very much for your attention to this since this is the only reply I've gotten to my various postings on this subject.

But at our company's first y2k meeting I brought up that using 'RR' for dates would cause a bug in all these programs in 2050. Management said they wanted to use 'RR' nevertheless because it would be easier for the operators and data entry personnel to continue entering two digits for the year. Anyway, they would be retired or dead by 2050 and this bug would create good jobs for their grandchilren and great-grandchildren. I said this was the type of thinking that created the y2k problem in the first place. They agreed with this assertion, but still insisted on using 'RR'.

So I must find out whether there are any known problems with using PL/SQL 2.x on the client side for Forms 4.5 by installing Oracle's patch on our PC's. I have severe trepidations that problems will occur, especially since I've now learned that Oracle first offered the patch on October 13. But the guy programming Forms 4.5 insists on using the patch, saying there is greater danger in writing all the additional code he would have to write if we didn't use the patch. The true pioneers are the ones with the arrows in their backs.

In article <01bf3158$51292fc0$a504fa80_at_mndnet>,   "Suresh Bhat" <suresh.bhat_at_mitchell-energy.com> wrote:
> Hi,
>
> No matter which way you go, including RR format, you will face the
problem,
> if the date falls
> outside the range 1950 to 2049.
>
> Our work around is as follows:
>
> You need to force the users to use 4 digit year to take care
> of this problem at the application level be it Forms, SQL*Loader or
> SQL*Plus.
>
> This is the way we have taken care of this measure in forms:
>
> Stop the user from entering a 2 digit year in the form.
>
> Set the date format mask to dd-MON-yyyy in the form, and trap
the error
> via the following procedure in the ON-VALIDATE-FIELD trigger for the
date
> item in the form if they try to use a 2 digit year.
>
> procedure check_date_format(pl_date in date)
> is
> BEGIN
> /* ************** Reference from LIBRARY
LIB_GNRL
> ************* */
> /*
> Format mask DD-MON-YYYY on date field does not
work
> properly.
> For example, date entered as 15-OCT-93 changes to
> 15-OCT-0093
> rather than 15-OCT-1993. This error is being
trapped by
> this
> procedure check_date_format and ON-VALIDATE-FIELD
trigger
> or
> KEY-NXTFLD trigger for the date field(s).
>
> Input parameter pl_date= date to be checked
> */
> if substr(to_char(pl_date,'DD-MON-
YYYY'),8,2) = '00' then
> message('Date must be entered in DD-MON-
YYYY format,
> Example
> 01-JAN-1993.');
> raise form_trigger_failure;
> end if;
> END;
>
> In your ON-VALIDATE-FIELD trigger on the date item you
simply need to
> call this procedure:
>
> check_date_format(:block1.date1);
>
> The procedure can be modified to accommodate appropriate date format
mask
> used in the form such as mm/dd/yyyy etc.
>
> Later !!!
>
> Suresh Bhat
> Oracleguru
> www.oracleguru.net
>
> avolbert_at_my-deja.com wrote in article <80uj92$g0$1_at_nnrp1.deja.com>...
> > Our company is using Oracle 4.5 Forms. Since 'RR' does not work
with
> > PL/SQL 1.x, Oracale has given us two options. On is to use an
Oracle
> > programming work-around on each Forms program that has a Y2K
problem.
> > The other is to use a patch to use PL/SQL 2.x on the client side so
> > that 'RR' can be utilized. Which of these solutions do you
recommend?
> > Is there any problem with utilizing 2.x? Does it mis-handle any
code
> > written for 1.x or does it cause processing slowdowns especially in
> > peak periods?
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Thu Nov 18 1999 - 23:19:39 CST