Re: Row values changing back to old values randomly???

From: Joel Garry <joel-garry_at_home.com>
Date: 27 May 2005 16:34:36 -0700
Message-ID: <1117236876.928788.270180@g47g2000cwa.googlegroups.com>

DA Morgan wrote:
> DG wrote:
> > DA Morgan wrote:
> >
> >>> Yes, that's probably what I will do. I will install good old
> >>> PostgreSQL and forget about Oracle.
> >>>
> >>> Thanks for your attention,
> >>>
> >>> David
> >>
> >>
> >>
> >> So because someone volunteering their time for free won't do what your
> >> DBA is paid to do you are going to change RDBMS products. Do you bring
> >> the same level of professionalism to your other endeavours?
> >>
> >> The fact that your DBA doesn't consider it worth his or her time gives
> >> a good indication of the importance of what you are doing. The fact that
> >> you can't talk to your own management gives a pretty good indication of
> >> the importance of what you are doing. If they won't give you the time of
> >> day why should we? But do remember that PostgreSQL is not Sarbanes-Oxley
> >> compiant so use it with care. Otherwise the Feds may have a few
> >> questions.
> >
> >
> > Ok, can I first suggest that we cut the buying/selling/professionalism
> > stuff and stay on the technical side because you got the situation
> > totally wrong.
> >
> > <situation>
> > First it's the customer's DBA who just went earlier home on Friday, but
> > his financial department wants to run our product on Monday. So, because
> > the customer's DBA wont support us on *his* DB, our options are limited
> > to either do his work or to install another DB for ourselves. So that's
> > the situation. And we are not in the U.S. so let's forget about the Feds
> > & Co. - I don't even know what Serbian-Ox is, and neither do I care -
> > the DB just has to run as expected, and the mentioned option has proven
> > itself as reliable numerous times.
> > </situation>
> >
> > So back to the technical side. I though about transaction isolation
> > levels. Is it possible that the database is configured to "READ
> > UNCOMMITED" isolation level by default? This would mean that the TOAD is
> > really showing data which hasn't been committed yet. Later the session
> > disconnects and the data is converted back.
> >
> > Thanks, David

> There are truly only three possibilities.

> 1. There is no commit and you don't realize it.

> 2. The commit is failing and your understanding of the Oracle
> transaction model is so weak you don't understand how to interpret
> what you are seeing or your code doesn't trap for the failure.

> 3. The commit is succeeding and you have a problem with caching
> on the application server or in your application.

4. The TOAD is looking from another session that started a transaction before the app server started it's update transaction, after looking from a session that started after the update transaction committed.

But I think 2 is pretty likely.

> I don't mean to be negative, irritating and/or rude but truly your
> comment above indicates a complete lack of knowledge of the Oracle
> transaction model so any one of the three is possible.

> What is absolutely impossible is that a commit is succeeding and
> the change is being rolled back by the database on its own.

flashhhhbaaaaackkkkk.

> --
> Daniel A. Morgan
> http://www.psoug.org
> damorgan_at_x.washington.edu
> (replace x with u to respond)

--
@home.com is bogus.
"PLEASE DO NOT REPLY TO THIS E-MAIL.  This e-mail address is not
monitored." - from replies_at_oracle-mail.com

Received on Fri May 27 2005 - 18:34:36 CDT