Re: Commit after transacton is completed

"Jim Kennedy" <kennedy-downwithspammersfamily_at_attbi.net> wrote in message news:J-
> Imagine that it is a banking application and you are adding interest to
> savings accounts. You either want to do all the savings accounts or none
> of
> them. So you use a transaction not commit every 500 rows. If you commit
> every 500 rows then people can see the changes before you are done and not
> all the changes, but some of them. So you would have created a bug. Bad
> idea.
> Jim
>

That is certainly one possibility of what the OP means by "transaction", but it is not likely in this particular case considering the number of rows he is updating.

Suppose that one has a "transaction" that physically deletes rows that were previously logically deleted (by setting the value of a status). The transaction only deletes rows from one table and the rows are not related to each.

In this case, the "logical transaction" is really one update (or delete in my example), however doing a commit for every delete is a waste of resources. But only committing after all the rows are updated (or deleted) is equally bad (as already noted). So committing every 1000 updates (or deletes) does make sense with such a "transaction". Received on Fri Nov 25 2005 - 08:57:39 CST