Not to beat a "dead horse", but if you use some finesse, there
shouldnt be a problem even if a patch creates a new bug. For example,
you patch a TEST database, announce the availability of the patched
database for testing, explain the importance of testing, and the the
importance of the patch. Explain the possible ramifications of not
testing. When nobody tests, whose fault is that?
cameron.cleland_at_ci.sj.ca.us (horse person) wrote in message news:<ee3c77d3.0305051152.57b512a4_at_posting.google.com>...
> PS...if you think just because your database is not generating error
> messages everything is hunky dory, I would suggest YOU check metalink.
>
>
> Daniel Morgan <damorgan_at_exxesolutions.com> wrote in message news:<3EB31E32.65448344_at_exxesolutions.com>...
> > horse person wrote:
> >
> > > There are no resources to test, that cannot change, so put that out of
> > > the equation.
> > >
> > > But keep in mind I am talking about FULL patchset, that has been out a
> > > LONG time, and installed by many many people. There is always the
> > > slim chance that it might cause a problem, but the good it does
> > > outweighs that. I would venture a guess that if you took 1000
> > > databases and compared how many were helped and how many hurt by an
> > > untested patch, the vast majority would be helped.
> >
> > When you say no resource ... I have done testing of the full Oracle
> > Financials suite on laptops. Exactly what software do you have that is so
> > large you can't create a test environment?
> >
> > That said my impression of your management is implicitly stated in my
> > previous comment if this is true.
> >
> > The fact that a patch has been out for a long time is a good indication no
> > problems will occur. If you think it is a guarantee I would suggest you
> > browse around http://metalink.oracle.com for a few days.
Received on Tue May 06 2003 - 16:18:07 CDT
