From: kschang77@eatspamhotmail.com
"Anne Wainwright" wrote in message
news:Xns98D7DC2E2D96Dazopane@196.43.2.61...
> When a user invokes a ctl-spacebar lookup does this place a table
> lock?
> Yes, I know it does.
>
> simply put
>
> Student --->> Purchase --->> Bookitems(which looks up from books.db)
>
> On my system, when one operator is searching for a record on the
> lookup,
> then a user on another machine is unable to calculate a total of their
> Bookitems.
>
> We solve this effectively if crudely by yelling across the room "will
> someone hurry up their lookup so I can get my total".
>
> Surely this can't happen on large systems with dozens of people using
> a
> lookup, the system would be unworkable?
>
> Is there any way around this? I thought about a button to play a tune
> to
> the offending lookerup, but something more elegant is needed I feel.
>
> I do have an automatic retry loop and a notice telling the operator
> what
> is happening and what to do.
Steve gave you one solution by fixing the CALC, which is the more
elegant way.
The other way is to simply make a COPY of the BOOKS.DB, call it
BOOKSTOO.DB, and base your lookups on the copy, not the original.
If any one edits the original, add a line to copy the table to the copy.
This
introduces the possibility of mismatch between the two copies (sync
problem), but unless you have very frequent edits of the BOOKS.DB
this will likely NOT be an issue. You could simply require a FULL LOCK
on BOOKS.DB editing to prevent anybody else from entering an order
while someone updates the BOOKS.DB, which would sorta makes sense.
And only release the full lock when BOOKSTOO.DB is updated as well.
--KC
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
