>I'm afraid I still do not see the "value" of ISRLOCKED()!
It's only value is that you know if you have already locked the record
or not. In case you do excessive multilocking and you want to keep count
of records you have locked, you use this. For anything like lockable(),
we know what it's worth - any millisecond the info it provides may
change - even the user who locked the record you want to lock may get
back from the toilet and release the record, or just lock it before your
nose. Anything is possible. That's why I agree with whoever said it: the
only way is to Get The Lock (and keep it while you need it), otherwise
any other info you may get is unsafe, temporary and practically useless.
>
>I *could* see its value *IF* it performed as documented [ does *anybody* have
a
>lock on the record ], BUT it does not. JimB diplomatically categorizes it as
a
>documentation ambiguity, but in fact the documentation is quite CLEAR and qu
it
>e WRONG.
The documentation is not clear and it is wrong. It says 'if the record
is locked', but doesn't mention who locked it at all. Omitting such an
important issue has surely led many people to some workhours lost over
it.
OTOH, the only one who knows if a record is locked is the file server;
in order to get such info, the app should ask the server or whatever the
filesystem the table resides on. I don't know what would such a call
involve (anyone volunteering for a .fll, or is there a way to get the
answer from some API call?), but it'd probably need some 'try to lock
and return OK if you make it'. It all depends on what's the possible
repertoir of calls, how much is it dependent on the network and/or
filesystem type etc etc. Doesn't sound easy so far.
>at a nanosecond or so later someone else could change the status, so a LOCKAB
LE
>() would really have limited value and good ol RLOCK() would still be the ult
im
>ate authority
I've already agreed with this.
>ISRLOCKED() certainly does *NOT* tell you if you can or cannot lock a record,
e
>ven as it functions presentl - it may tell you that YOU do not have a lock on
t
>he record, but it says nothing about OTHERS having a lock on it!
Yes, and the help doesn't say so. I've been disappointed exactly the
same (luckily, it was when I've read about it here, so I didn't stumble
over it in any of my apps - thanks folks).
>Call me thick, but ISRLOCKED() remains useless to me.
Would 'thin' be any better :) ?
