Re: Checking for uncommited transactions

Galen Boyer wrote:

> Yes, I misunderstood your previous statement. But, how does keeping
> transactions on the server solve anything (You said "Transactions
> should allways be started and commited on the server EXPLICTLY")? Bad
> transaction habits can happen on server side just as well.
>
> I take a different route. I don't want any transactions within any
> application PL/SQL code (unless we are talking batch processes). This
> would mean that some other database or application process could call
> that code and have a commit happen without them meaning to. A
> transaction is a business defined unit of work. Let the business
> logic define the transaction's boundaries. If there is an error in
> the business code so that transactions are left open, then fix that.
> Don't jump to the conclusion that all transactions are server-side.

What I meant is that transactions should not be commited/rollbacked from the client app.

Look at our scenario. Let's assume the client will crash/hang after the insert or the user leaves his workstation. In this case _no_ user is able to delete a record in USERS.

To avoid this problem (in most cases) all transactions should be encaspulated in pl/sql code. After the excecution no transactions should be open anymore.

In simple words: Don't give the end-user the control over transactions.

-- 
Immo Landwerth - XP Pro - D5 Pro SP1 - XanaNews 1.14.1.1