Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Multiple users updating subfiles

Status
Not open for further replies.

vecam

Programmer
Aug 26, 2003
7
US
Using RPG IV, I wrote a barcode scanning program that updates a file and displays a record in a subfile.

Problem: When two users are accessing the program at the same time, record locks occur. Tried using unlock after update of file, but subfile displays same record on screen for both users instead of the two different records that were processed. The file however, is updated correctly with each user's scan.

I need the subfile to reflect each user's scans, and not display same record.

Thanks for any help!

 
Updating a file unlocks it by definition. You need to reload the subfile after each update to keep the information current. And to avoid locks, first chain to the file record with no lock. When updating, chain again with a lock, change the information, and update the file record immediately.

You may want to put some hidden fields in the subfile so you can check to see if another user has changed the file record since the current user chained to it.


"When once you have tasted flight, you will forever walk the Earth with your eyes turned skyward, for here you have been, and there you will always long to return."

--Leonardo da Vinci

 
You should read the file without locking it while loading the subfile. In RPG/IV this can be done using
Code:
KeyField       Chain (N)  FileName
-or-
               Read  (N)  FileName
Reading the next record also automatically unlocks the previous record so did the users only get a lock when they both tried to access the last record in the file?

PeteJ
(Contract Code-monkey)

It's amazing how many ways there are to skin a cat
(apologies to the veggies)
 
No, they received the lock anytime each user referenced the same ticket# (the key is based on ticket# and another field).

The logical file has a key that is not unique. When a record is read from the file, I have a DOWEQ loop to get all the matching records of ticket# and the other field and update the appropriate fields. After the DOWEQ loop the subfile record is built to display to the screen for the user. What is happening is that the file gets updated with both users scans but, when I display the info back to the screen in a subfile, I get a lock on the READ statement in the DOWEQ loop. The first user's scan displays the correct info on that screen, however, the second user gets a lock on the READ statement and no display of data on screen.

I am trying shared update in the OVRDBF for the logical file, and UNLOCK for the logical file after the DOWEQ loop to see if this will fix the problem.

Any suggestions?




 
Is this file under commitment control?


"When once you have tasted flight, you will forever walk the Earth with your eyes turned skyward, for here you have been, and there you will always long to return."

--Leonardo da Vinci

 
No, How do you put commitment control into a program? I am new to this procedure.
 
Commitment control - I just asked because that record locks wrok differently under commitment control. It's been seven years since I've had to deal with it, and I'm not really sure anymore.

Anyway, ideally, only one user should be in the record at any given time to update it. The other user has to wait for the first one to update the record (thereby releasing the lock).

Try this

key chain(E) file

select
when not %error

... normal processing

when %error and %status = 01218

... record locked by another user

endsl



"When once you have tasted flight, you will forever walk the Earth with your eyes turned skyward, for here you have been, and there you will always long to return."

--Leonardo da Vinci

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top