Subject | RE: [IBO] IBO & Update Trigger Problem |
---|---|
Author | Helen Borrie |
Post date | 2003-02-10T00:18:53Z |
At 09:25 AM 10/02/2003 +1100, Alan McDonald wrote:
with server code. If you can't avoid client code that does so, then you
MUST write your triggers so that they are aware of this. An example would
be where you are using IBO's pessimistic locking. You have to make any
update trigger aware of the locking code and ensure that the trigger
operations bypass it.
An important design point is that "client-awareness" in server code is a
time-bomb. It should be minimised to the greatest possible extent, to
avoid binding the database to one particular application. I can tell you
some really hair-raising stories about some of my contract customers in
this vein....
Helen
>Eric have you thought about making the update trigger of the master do thatI agree wholeheartedly with Alan. Never write client code that conflicts
>update work, and not the update trigger of the detail? I would have to admit
>that I would never make my design work the way you state it does. It just
>smells flawed. I suppose that if you have to do it this way, then why are
>you making the update statement of the master include the field value which
>is being controlled by the detail update trigger? Just remove it from the
>update statement fo the master.
with server code. If you can't avoid client code that does so, then you
MUST write your triggers so that they are aware of this. An example would
be where you are using IBO's pessimistic locking. You have to make any
update trigger aware of the locking code and ensure that the trigger
operations bypass it.
An important design point is that "client-awareness" in server code is a
time-bomb. It should be minimised to the greatest possible extent, to
avoid binding the database to one particular application. I can tell you
some really hair-raising stories about some of my contract customers in
this vein....
Helen