Re: Lock timeout on oracle 8i

Before i join to this company the current aplications were developing, so i just continue to support them to keep the current aplications running as they aspected.

In parent table has column named 'posted' can contains true or false value, when the value is true the record couldn't be changed.

The lack is when a user is updating the detail records, another user change the posted column to be true, this event can makes the transaction records and summary records in other table isn't match, so to solve this problem we need this locking mechanism. Although this event rarely happen but we need to minimize it.

Thanks in advance,

Rudy Susanto

yong321_at_yahoo.com (Yong Huang) wrote in message news:<b3cb12d6.0205271404.651aae5a_at_posting.google.com>...
> By update the parent record, you mean updating the primary key or
> other columns? Updating the primary key never or rarely happens. If
> you update other columns such as the department name in the sample
> scott/tiger schema, there's no locking, whether you delete an employee
> or update the employee record.
>
> Your original code is good as far as handling ORA-54 is concerned; you
> wait some time and try to lock the row again in the hope that the row
> is no longer locked by other sessions.
>
> Yong Huang
>
> rsusanto_at_atlas-sp.com (Rudy Susanto) wrote in message news:<1a928d0b.0205262331.77ccae3c_at_posting.google.com>...
> > Actually we already have some applications with sqlserver database.
> > And my question is what is the right way to us if we want our
> > applications can does the scenario like this:
> > I have 2 tables, parent and child table, if a user update or delete
> > child record, another user will never allow to update the parent
> > record that have relation with it. So before a user can update or
> > delete child record, the parent record must be locked first.
> >
> > I know this mechanism is not good, but i can't change the existing
> > applications as i want at this time. In my opinion i rather consider
> > to redesign the database before migration, after redesigning the
> > database we do not need explicit locking anymore but i have to discuss
> > this problem with the related staffs.
Received on Mon May 27 2002 - 21:07:51 CDT