Re: Commit after transacton is completed

"Mark A" <nobody_at_nowhere.com> wrote in message news:K8adncjAi9DnrhrenZ2dnUVZ_vydnZ2d_at_comcast.com...
> "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in message
> news:ceceo1d2fuk77b5vemh46g354letjr55av_at_4ax.com...
> >
> > Actually it isn't bad at all (as also already noted), if you are aware
> > what a transaction is.
> > Status flags are just a hack implemented by developers exposed to
> > lousy commercial software and equally lousy products forcing you into
> > single record commit.
> > One should address the causes, and stop implementing further hacks.
> > --
> > Sybrand Bakker, Senior Oracle DBA
>
> There are a lot of people in this thread who confusing a logical
transaction
> with a physical transaction. There is no evidence that the OP meant a
> "logical transaction" he said transaction. In fact, it is very unlikely
that
> a logical transaction consists of as many updates as the OP stated.
>
>

We don't know enough about what he is trying to do. But in all likelihood the update #1 is updating information that update #2 needs to know about. (eg it might do something different if the row is updated or not) Usually one needs the rows to be consistent. Sure sometimes an update is to alter a column that "doesn't matter to everything else" (eg upper a first name field for all records and another process wants to change the birth date of some records.) In that example, then one could do the thing piecemeal as the OP wants. But in most cases it is a bad idea.

I'm sorry I have to agree with Sybrand on this one. The whole logical vs physical transaction thing is application laziness and poor coding practice. I have seen so many commercial apps take this approach and frequently get wrapped around their axels because the they are trying to do rollback in the application. Yech! Orphaned records, and bits of turds in the database over time.

Jim Received on Fri Nov 25 2005 - 12:20:18 CST