pro-iv record locking question
Posted 06 February 2012 - 02:15 PM
I have a paging screen where a user can modify records in a table.
I have another update function that reads through this same table in delete mode to try and process these records and delete them.
Once I go into a record in the paging screen, if I try and run the update function, it will just hang until I exit out of the paging screen (without any type of message), then it will finish.
I want to be able to ignore the record that is being locked and just process the remaining records in the update function.
I put DSEL in the after read error logic and record lock logic in the update function, but it doesn't seem to get to that code since I also have messages to display and they do not get displayed.
Even if I get out of the record in the paging screen and scroll down to other records, it seems to keep locks on one or more records.
Any suggestions on how to handle this? Thanks.
Posted 06 February 2012 - 05:06 PM
Here is what I have:
Key field - list of files to be read:
File: XXXX ACDL
Update program (loops through file XXXX):
Primary File - XXXX Mode: D
Record Lock Logic:
If I sit on a record in the paging screen, then start the update, the update shows: UPDATE IN PROGRESS - PLEASE WAIT until I exit out of the paging screen.
In the Lock Logic (in the Update) you need to put the code:
This tells the Function to stop waiting on the lock on this record.
Posted 06 February 2012 - 09:01 PM
Try setting up the update as:
Primary File XXXX L
02 XXXX D
(i.e. have the file in twice with the Primary in L mode, then as the second file in D mode (with the SUPPRESS_RETRY Lock logic on File 2).
Posted 09 February 2012 - 10:22 AM
What database are you using ISAM, ORACLE ?
You have described that there is a screen function where a user can change records
an update function that another user/session can delete the same records
The user in the screen is not going to have a good user experience, that records they have selected for processing in a paging screen are deleted at same time by another process/user.
A possible solution (I have used this in past)
re-design the screen function
a) in an update function load the selected keys and maybe some data fields into a workfile
perhaps you could set a value on the data record to show that this record is on-hold/selected for processing
(generally I'd record OPR id and process-function that has selected/held the data record)
use this file as the primary file in your paging screen and the user changes values on this file
c) on exit from the paging screen call an update to apply the changes captured.
Make sure that you remove the value that identifies the record(s) is being processed.
If the update finds that the data record(s) has been deleted (no longer present) then you could present the keys of the missing records on an error report/screen to the user.
you could also re-design the update function
a) read the table fist in Lookup mode and check the value on the data record that identifies if a record has been selected by another process - is lready seleced than DSEL.
Then read the table for a 2nd time in Delete Mode
Hope this helps
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users