Re: Checking for uncommited transactions

FC wrote:

> Well, each user is updating his own stuff, so this is one of those lucky
> situations where I am 100% sure there are no concurrent changes to the
> same record.
> Volumes of data are very low, so performance is not an issue, I just want
> to give a quick "undo" possibility to the user without having to check
> table by table and record by record what he has changed.

I'm seriously missing the point of why you want to perform a manual programatical undo from the client, and not within Oracle.

> If I don't allow rollbacks at the db level, then I must write my own
> rollback at the client level, which violates the first law of the good
> programmer: do not reinvent the wheel.

But you are violating the basic law of transactional processing. Why can you not "allow" rollbacks? Why then use Oracle in the first place? Why not give each user his own flatfile? Share that via netBIOS or NFS mapping.

> So, in the end, since I do not need to check for selects of other users,
> is there any other strong objection for not querying v$locked_object?

Common sense?

Quantity of data has nothing to do with it. Nor the number of users. Or whether or not each is updating his "own" stuff. There are certain basic and fundemental principles in OLTP - and one of these is that "Thou shalt use database transactions".

Or am I missing your point totally?

--
Billy