Locked record

[Bruce Easton]

On 5/27/10 1:18 PM, Bruce Easton wrote:
> 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
>    
Sheez - and if that's not enough - and it really outta be - I'll say 
something for any new filepro programmers (but are there any :))   And 
that is, after resolving the locked record issue, if it was done in a 
way other than a normal exit by a user from the application holding the 
lock (i.e., reboot, processes killed), then it would be a good idea to 
put the lockfile back into a good state by getting everyone else out of 
the file and clearing the lockfile via filepro (and I think if on 
windows, to do this sometimes requires that you get everyone out of all 
qualifiers for a file and then clearing all of the locks - qualified and 
not for the file).

All of this because, I believe, as soon as you get involved in killing 
processes and reboots, you're not allowing filepro to finish its 
lockfile maint. chores.

Bruce