The most consistent way to have locking problems is to lock around user
input.   The first rule I learned while starting to program using Image was
never to Lock and then go to the user for any input.  It doesn't matter
what kind of lock you are using.

Sometimes it makes for difficult programming especially if you are updating
data and you want to maintain consistency in the database while allowing
user input.   You can do it with the initial reads, then proper locking on
update, re-reading and comparing the data.  Sometimes you have to reject
input as the data has changed in the time between the original read and the
re-read, but you can avoid problems of the user 'walking' away while the
program waits for input.   The likelihood of the data changing depends on
many factors, but with proper forethought this can be minimized.    If a
user walks away after the read, then comes back (say after lunch) and does
the update, when the input is rejected, there are no excuses for the users
actions (and by that I mean starting the update and leaving for lunch!).

RON HORNER wrote:

> The single problem that I find with unconditional locking is the human
> element.  Someone walking away as the lock is applied.  Basically hard
> locking data so that no one else can get to it.
>
> The other point is keeping track of what programs are doing what kinds
> of locking.  If a program that conditionally locks a record and another
> program that does hard locking tries to lock the same record, make sure
> there is something in the hard lock program to keep trying and not blow
> up.
>
> That's it for me.
>
>         -----Original Message-----
>         From:   Greg McDaniel [SMTP:[log in to unmask]]
>         Sent:   Wednesday, November 18, 1998 4:57 PM
>         To:     [log in to unmask]
>         Subject:        TurboImage Locking
>
>         Could someone tell me if there are any problems with some
> programs doing
>         conditional item level locks while other programs are doing
>         unconditional item level locks.  The programs are all locking
> the same
>         item.  All of our code currently use conditional item locks but
> we would
>         like to move to unconditional locks for some applications.
> Hence we
>         would end up with a mixture of conditional/unconditional item
> locks.
>
>         TIA
>
>         Greg



--
Jim Alexander   Longs Drug Stores
Sr. Systems Programmer  925-210-6901
The opinions expressed are Mine and not Longs Drugs