Re: Y2K for NT and Oracle

The reactions of your managers sound VERY familiar to me. I faced the same problem in 1989, when I was trying to force operators to enter four digit years. I wasn't fired (yet) but I didn't make myself popular. PL/SQL 2 to be sure is NOT a major upgrade. This is all marketing hype, as years ago they sold sticking with PL/SQL 1 as 'application partitioning'. I made the transition at the server side years ago and I said 'Is that all there is'

Hth,

--
Sybrand Bakker, Oracle DBA
<avolbert_at_my-deja.com> wrote in message news:812ml8$sa$1_at_nnrp1.deja.com...
> 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 Fri Nov 19 1999 - 13:08:29 CST