Re: Y2K for NT and Oracle

You gotta know when to hold 'em,
Know when to fold 'em,
Know when to walk away,
Know when to run.

Thank you for your reply on your installing SQL 2 on the server. This gives me a far more positive feeling about our installing it on the client. I also feel more positively because so far no DBAs such as yourself have heard about any system problems due to installation of SQL 2 on the client for Forms 4.5. No news is good news. For safety's sake, however, I would still like to hear from anyone who has had experience with a system using Oracle's Oct. 13 patch on the client side.

Arthur Volbert, Senior Programmer-Analyst

In article <943038579.25305.0.pluto.d4ee154e_at_news.demon.nl>,   "Sybrand Bakker" <postmaster_at_sybrandb.nospam.demon.nl> wrote:
> 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.
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Sun Nov 21 1999 - 00:29:12 CST