Locked record

[Bruce Easton]

On 5/27/10 1:07 PM, Bruce Easton wrote:
> On 5/27/10 12:47 PM, Fairlight wrote:
>    
>> Four score and seven years--eh, screw that!
>> At about Thu, May 27, 2010 at 12:21:29PM -0400,
>> Kenneth Brody blabbed on about:
>>
>>      
>>> Okay everyone, repeat after me:
>>>
>>>        The lockfile has nothing to do with record locking.  Nothing.  Nada.
>>>        Zip.  Zilch.  Zero.
>>>
>>>        
>> Ken?  Does the lockfile have anything to do with record locking?  I keep
>> hearing, "Yes," and I'm still confused after all these years.
>>
>> mark->
>>
>>      
> I don't believe Ken has ever said anything that would contradict what
> you quoted him as saying above.  As for anyone else, to me a 'yes'
> answer is wrong.
>
> My understanding has always been that the lockfile's purpose pertains
> only to simultaneous access to the entire file between the various
> executables - primarily ddefine vs. clerk/report or dxmaint vs
> clerk/report  or dxmaint vs. ddefine, etc.
>
> But what might be a more useful question is:  is there any way that a
> locked record can prevent filepro from performing its normal maintenance
> of a lockfile, and if so, does that differ on Windows vs. *nix?
>
> Bruce
>
> Bruce Easton
> STN, Inc.
>
>
>    
Gosh  - now that I think a bit more, I guess the answer to my proposed 
'useful' question should be obvious.  Of course filepro has to manage 
the lockfile in and around the record-locking going on.  So if a record 
stays locked longer than expected, then of course you would expect 
everything else to be waiting on it.

But trying to resolve the locked record issue by going after the 
lockfile is definitely not going to help.  Got to find and get the 
person off the record who is still using the record, or kill process or 
reboot as previously suggested, but I'll have to try that tool Ken 
mentioned.

Bruce