| Subject | Re: [IBO] Pessimistic Record Locking |
|---|---|
| Author | Lester Caine |
| Post date | 2005-04-09T06:41:20Z |
Matt Nielsen wrote:
wrong path ...
I don't use CachedUpdates simply because it is DESIGNED to allow you to
work independently of the server.
Simply bodging things to get round an initial mistake will cause a lot
more trouble than actually fixing the fault. The side effects of your
bodge will be worse than fixing the original process flaw. I know I've
been there ;)
That said, I don't use Pessimistic Locking either.
I have a field in the record that flags who is editing a particular
record (in my case which counter it is on) and while that is set other
users get a message that the record is in use. I set that flag with a
staff_id and clear it with the later post. *SO* you could add and post
that before going onto the cachedupdates section, and prevent a user
going into edit mode if the record is already in use. This needs a
little more management than a simple lock, but does mean I can say 'X'
is editing record, and if 'X' is, then I check that 'X' is actually
still logged in - overriding the flag if they have logged off before it
is cleared.
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
> I have a system that has a high probability of two users editing aYou are not going to want to hear this, but since you are already on the
> record at the same time so I need to implement Pessimistic Locking so
> that when one user goes into edit mode it prevents other users from
> editing unti the first user commits their changes. However, I am using
> CachedUpdates, good or bad that is what we are using and I cannot
> easily change that at this point do I don't want to argue that point.
> I just need a way to do pessimistic locking with my existing
> cachedupdates and my TIBOQuery objects.
>
> I've looked at the IBO code and everything gets skipped when you use
> cachedupdates, how can I bypass the IBO internals and lock my record.
>
> BTW I want to move away from cachedupdates but I have over 200 queries
> right now using it and I can't deal with the side effects of turning it
> off right now.
wrong path ...
I don't use CachedUpdates simply because it is DESIGNED to allow you to
work independently of the server.
Simply bodging things to get round an initial mistake will cause a lot
more trouble than actually fixing the fault. The side effects of your
bodge will be worse than fixing the original process flaw. I know I've
been there ;)
That said, I don't use Pessimistic Locking either.
I have a field in the record that flags who is editing a particular
record (in my case which counter it is on) and while that is set other
users get a message that the record is in use. I set that flag with a
staff_id and clear it with the later post. *SO* you could add and post
that before going onto the cachedupdates section, and prevent a user
going into edit mode if the record is already in use. This needs a
little more management than a simple lock, but does mean I can say 'X'
is editing record, and if 'X' is, then I check that 'X' is actually
still logged in - overriding the flag if they have logged off before it
is cleared.
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services