So the problem is that you are using derived data - that is calculated
data - and by making a change in a child record you are potentially making
this calculated data wrong. Bad design no matter what the database is.
Jim
"Rudy Susanto" <rsusanto_at_atlas-sp.com> wrote in message
news:1a928d0b.0205271807.77b720e0_at_posting.google.com...
> 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 - 23:33:13 CDT
