Jump to content


Photo
- - - - -

pro-iv record locking question


4 replies to this topic

#1 bschroder

bschroder

    Newbie

  • Members
  • Pip
  • 4 posts
  • Gender:Male

Posted 06 February 2012 - 02:15 PM

I have a question about record locking in pro-iv (superlayer). Pro-IV version 4.6000 5.3.8 Superlayer version 7.00000 r101.05


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.

#2 Chris Pepper

Chris Pepper

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 369 posts
  • Gender:Male
  • Location:United Kingdom

Posted 06 February 2012 - 04:03 PM

In the Lock Logic (in the Update) you need to put the code:

SUPPRESS_RETRY()

This tells the Function to stop waiting on the lock on this record.

Edited by Chris Pepper, 06 February 2012 - 04:05 PM.


#3 bschroder

bschroder

    Newbie

  • Members
  • Pip
  • 4 posts
  • Gender:Male

Posted 06 February 2012 - 05:06 PM

Thanks for the feedback! I tried that, and it doesn't seem to work.

Here is what I have:

Paging screen:

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:

SUPPRESS_RETRY()

DSEL



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:

SUPPRESS_RETRY()

This tells the Function to stop waiting on the lock on this record.



#4 Chris Pepper

Chris Pepper

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 369 posts
  • Gender:Male
  • Location:United Kingdom

Posted 06 February 2012 - 09:01 PM

OK - re-reading the manual suggests that SUPPRESS_RETRY() may only work on a secondary read.

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).

#5 George Macken

George Macken

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 248 posts
  • Gender:Male
  • Location:Co. Wicklow, Ireland

Posted 09 February 2012 - 10:22 AM

Hi

What database are you using ISAM, ORACLE ?

You have described that there is a screen function where a user can change records
AND
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)

B) 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

Rgds

George



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users