FYI: Locking records

[Howard Wolowitz]

FYI :

Running filepro 5.0.14R4 under Linux.

I just ran into a situation where filepro locks records that I was not aware 
of before.  It probably is not a bug* but it might help explain times when 
our users have reported locked records that, until now, we had no idea how 
or why the locking happened.

I offer this email in the hopes that it helps others solve their own record 
locking issues.

We all know that if you do a lookup to a record and you are planning to 
update data on that record, that you should use the -p flag to lock the 
record at the time of lookup.  I was also aware that if you didn't 
explicitly lock the record, filepro would do so as soon as it encountered 
the update operation.  I.E.:  pay(123)="xxx".

What I didn't know until yesterday was that when using an exit key (xkey=) 
on a browse lookup, where the @bk processing modifies the looked up record, 
at that moment _all the records shown on the browse window get locked_!

It showed up because of the particular design of the application I am 
writing.  I am standing on a record in a header file "A" and doing a browse 
of a detail file "B".  (Using show=pkeep).  The exit keys allow me to add, 
edit, remove and re-number the detail records.  But the adding and editing 
are done via a system command to rclerk on the detail file.  It worked fine 
until I did a re-number or remove operation, which is done by modifying the 
fields directly in the looked up record.  Once that happened I could no 
longer edit any of the records because I got a "Record is being updated ... 
Access denied" kind of message.  No matter which record I choose to update. 
All the records shown in the browse were now locked.  (The actual message 
occurred when file B tried to go into update mode on the record and was 
simply reporting that file A had it locked.)  If I had stayed on file A to 
do the editing operation it would have worked because I would have owned the 
lock, but it would have covered up the fact that all the records where now 
locked.

The work around (actually the proper way to do it) was to save the record # 
of the record to be modified, close the original lookup, issue a lookup to 
the required record, using the -p flag, make the changes, close it and then 
go back to the original browse lookup.

I did expected filepro to lock the record I was modifying but not to lock 
all the records shown on the browse.  It acted as if it had re-issued the 
browse with the -p flag.

Perhaps the behavior is changed it later versions of filepro?

Howie
*- A bug is defined as software operations not in accordance with published 
specs.