Record Locking

[Nancy Palmquist]

Here are my responses.  Most of these things happen and it depends on 
the kind of database and users on your system so I can not say any are 
more likely than others.

On 4/12/2021 8:45 PM, Jose Lerebours via Filepro-list wrote:
> What do you attribute your record locking issues most often to
>
> A. Two or more users trying to update the same record
This depends on the type of data and the construction of the database.  
I would see this more often on databases where 2 users had to access the 
same customer or item in the nature of the data entry.  Not so much when 
people are doing orders or adding inventory or something where the jobs 
of the people are focused on one category of work.
> B. Running a report while a user is in update mode
I would say this is the most common.  But I would make 2 observations, I 
use -u when the report is not required to update records as it passes.  
But I do not use -u when that is necessary, so the report should wait 
for the user to finish what they are doing before continuing.
I wish filepro had a better way of handling this, than just waiting.  It 
can be very confusing for the users.

> C. Rebuilding indexes  while user is in update mode
Scary bad, I try to rebuild things off work hours, if they need that 
kind of attention.

> D. User closed connection leaving a lock file behind
Lock file is different than a record lock.  This is somewhat common and 
can be annoying, but it is also bad to just do an unlock without 
checking to see if two functions will collide.

> E. Lookup processing that locks but does not release record
I see this often on Windows Server versions and the only way to release 
this is to reboot windows.  On a project where the data entry is done 
from a dummy file, it is obvious when locks are stuck that it came from 
lookups.  I am of the opinion that filepro is too fast for Windows 
Server systems.  I will often have to put in sleep commands to give 
Windows time to update data and remove record locks before I continue.  
It is a shame but it saves quite a bit of problems in the long run.

I have seen invoice numbers that need to be generated sequentially, and 
when 2 users are pulling numbers, it will get duplicates even when the 
record is opened with a lock and written when updated to release the 
locks.  Somehow both users are able to get the same number.  My 
conclusion is that the lock was not seen by the second user, who was 
able to access the record before the lock was applied.  Even though the 
lock command was sent before the data was pulled.  I had to invent a 
workaround for this to insure it never happened, but it should have 
worked without that being necessary.



>
> To me, (B) was the most common record lock instances till I decided to 
> run reports ignoring this and just keep on moving.
>
> I rarely ever heard of two users trying to update the same record - I 
> do remember seeing situation where a user will use the arrow up/down and
> reach a record where a user was sitting in update mode and the 
> "waiting for record to be unlocked ..." came up; even without any 
> processing being triggered.
>
> Do not hold me to "even without any processing being triggered" part 
> of the above statement but I am at least 80% sure of it.
>
> What about you?  What would be your most frequent reason?
>
>

-- 
Nancy Palmquist         MOS & filePro Training Available
Virtual Software Systems    Web Based Training and Consulting
PHONE: (412) 835-9417           Web site:  http://www.vss3.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20210419/f001a52a/attachment.html>