Subject | Re: [IBO] PessimisticLock option |
---|---|
Author | Nando Dessena |
Post date | 2003-07-24T06:38:28Z |
John,
J> I have just conducted a bunch of tests with the PessimisticLock=true on a
J> query and have discovered that any before post and after post triggers get
J> executed twice. I did the tests in D7 with FB1.0 and FB1.5. I tested with 2
J> versions of HA and Hi before testing Ie. If I turn the lock to false the
J> triggers fire up just 1 time.
a search in the archives would have saved you the bunch of tests. ;-)
Pessimistic locking in IBO is achieved through "dummy updates", so if
you don't want the update triggers to do anything you should put their
code under conditions (eg. if (old.field <> new.field). You cannot
prevent them from running altogether, though.
Alternatively, if you use Fb 1.5, you could take advantage of its new
pessimistic locking capability. Issueing a
select * from table where id = :id with lock
should get you all the benefits of pessimistic locking without firing
the update triggers.
HTH
--
Nando mailto:nandod@...
J> I have just conducted a bunch of tests with the PessimisticLock=true on a
J> query and have discovered that any before post and after post triggers get
J> executed twice. I did the tests in D7 with FB1.0 and FB1.5. I tested with 2
J> versions of HA and Hi before testing Ie. If I turn the lock to false the
J> triggers fire up just 1 time.
a search in the archives would have saved you the bunch of tests. ;-)
Pessimistic locking in IBO is achieved through "dummy updates", so if
you don't want the update triggers to do anything you should put their
code under conditions (eg. if (old.field <> new.field). You cannot
prevent them from running altogether, though.
Alternatively, if you use Fb 1.5, you could take advantage of its new
pessimistic locking capability. Issueing a
select * from table where id = :id with lock
should get you all the benefits of pessimistic locking without firing
the update triggers.
HTH
--
Nando mailto:nandod@...