Re: Checking for uncommited transactions

Billy Verreynne wrote:

> However, seeing that you're deal with something like Visual Basic that
> sucks when it comes to OO programming..no wonder you're confused.

Any language is as bad as other languages ("Before C++ we had to code all our bugs by hand; now we can inherit them") :-) But now we are talking about VB - this is an Oracle Newsgroup. Lets get back to the main point.

IMHO you have done a basic design mistake: Don't give the control about transactions to the client. Transactions should allways be started and commited on the server EXPLICTLY. Consider, that if you have an open transaction, linked *tables* are locked.

Lets see why.

Assume you have a table USERS and a table USER_SETTINGS. They are linked by the column USER_ID (one user - many settings). If you insert a row in the USER_SETTINGS table, Oracle ensures that a row in table USERS exists with the passed USER_ID (assuming declared ref integrity).

While Oracle waits for a COMMIT/ROLLBACK the table USERS remains locked for DELETE operations. Consider, I speak about the table not a row! This happens, since Oracle has to ensure that all regarding rows in USERS exists until you perform a commit. Otherwise other Oracle users may delete the USER, because they don't see any row in USER_SETTINGS.

This means other Oracle users cannot DELETE any row in table USERS.

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