Re: Checking for uncommited transactions

Galen Boyer wrote:

> No, what you should do is wait until the client has hit a submit
> button and then do all of the DML and commit, as one single unit.

That's what I wanted to say. But FC said this:

> Hang on a minute, one can design a screen that contains two forms in
> two different tabs. This screen is a "logical" unit, so, switching
> from one tab to the other doesn't mean you have to commit or rollback.
> You can defer the commit or rollback until you exit from the "main"
> screen.

This would mean that the end-user has too much control over the transaction. He opens the form, changes a lot of stuff (causes several inserts, updates or deletes) and commits when closes the form.

> Your problem is that you allow client's modifications to take place
> over a long time span (ie, allowing for think time during the
> transaction). You need to keep all of the modifications in the app
> until the modifications that define the transaction are ready to be
> submitted. Until that time, no database modifications should be made.

This is exactly what I said: Encapsulate the transcation in a logical unit. In my expierence the best way of doing so is an encapsulation in PL/SQL code on the server (package). Of course the code can also be sent from the client app. But keeping code in the server has many advantages. Transactional based code is allways one of the more important code passages and therefore it should be kept in the server. I know this doesn't improve the transaction it self.

> Completely untrue. A transaction is a business rule. A business user
> is one who enacts this rule. The application gives them the facility
> to enact the rule.

Correct. But don't give the user these three buttons: Insert, Commit and Rollback. According to Murphy's Law the user will neither press commit nor rollback until he has finished a two hour telephone call :)

Do we share the same point?

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