Re: Checking for uncommited transactions

FC wrote:

> Moreover I never mentioned Oracle Forms, I never used it in my life, I am
> talking of a more general concept of form like a form created in VB.

Data bound controls, huh? That's Bad Thing (tm).

The client initiates the transaction in Oracle. The user then selects to change the fields on the form.

He selects the "save" button. The data controls sends a commit through. Not a problem.

He selects the "cancel" button. The data controls sends a rollback through. Not a problem.

He exits the form without selecting either. A problem. What does the data control's destructor do when it's called and there's a pending transaction?

What you can do (maybe not in VB as it sucks as OO language) is to subclass the data control if it does not have a property stating whether or not there's a pending transaction - and create such a property.

On the form's destructor method, you enumurate all data control objects and check that property.. and then decide whether to commit or rollback.

Or.. much simple and safer.. you simply rollback all data controls in the form's destructor. After all, the user did cancel the form without electing to save the changes he made to the database.

The problem you dealing with has IMO very little do with Oracle itself, and everything to do with how well behaved the client is wrt how it selects to start and end database transactions.

As that is done by the client, you should be able to write code _in_ the client to keep track of what transactions are pending. You don't need Oracle system tables for that. IMO.

--
Billy