Locked record
Bruce Easton
bruce at stn.com
Thu May 27 10:18:25 PDT 2010
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
More information about the Filepro-list
mailing list