{{tag>category:"OpenInsight 64-bit"}} [[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]] ==== Locked records, who has a record locked. (OpenInsight 64-bit) ==== === At 28 FEB 2024 08:01:42PM Richard Hunt wrote: === For years I have wondered why there isn't a anything that offers that information. So just recently I looked into it, and here is what I finally did about it. 1) MFS LOCK.RECORD (5), Only offers two answers to who has the lock... you or someone else. I think this is Useless information. 2) MFS LOCK.RECORD (5), will not pass to other MFS's if the lock is already locked. That kills off any chance of your custom MFS to report who has the lock. Another useless developer stopper. 3) MFS LOCK.RECORD (5), user help talks about "semaphore". lame information. Needed is the file name, record id, and the application of the lock. What you get is a file handle and a record key. What I have figured out by theory and trial and error is the following... You can not or I have not figured out how to do it... is to work with RTP36 (lock processor). i can not pass or get information from this program. It would be the easiest to modify this program like you would the MSG program. You can not replace RTP36 Like you would do MSG because the system will crash. OK given that I looked at the LOCK statement and realized that it has three bits of information it probably passes to RTP36. The file var, file key, and the lock type. I also realized that RTP36 must use a common variable to keep track of record locks since if the record is locked already then it does not call a MFS. If so then it is most likely that element 0 of the common variable is not used. If that is true then all that is needed ts to update the element 0 of the common variable at the proper location with @STATION. Given all that, if my theory is correct then there are two ways to solve this... 1) Revelation does a 2 line modification to RPT36 something like this... COMMON_VAR(0) = @STATION at time of lock. @ANS = COMMON_VAR(0) at time it is found that record is already locked. then we could use LOCK FILE_VAR, RECORD_KEY ELSE MESSAGE = 'Record locked by ':QUOTE(@ANS) END Oh so simple! I mean I did all the thinking for you (unless I am wrong, and I doubt I am). The second solution would be to just let us know the common variable name and element count, then we could change element 0 ourselves. again oh so simple! I do not think it is so secret or a source code risk to let us know the common variable name. Otherwise I will just have to use the programming I did in a custom MFS to duplicate the lock process. ---- === At 28 FEB 2024 09:18PM Barry Stevens wrote: === For years I have wondered why there isn't a anything that offers that information. So just recently I looked into it, and here is what I finally did about it. 1) MFS LOCK.RECORD (5), Only offers two answers to who has the lock... you or someone else. I think this is Useless information. 2) MFS LOCK.RECORD (5), will not pass to other MFS's if the lock is already locked. That kills off any chance of your custom MFS to report who has the lock. Another useless developer stopper. 3) MFS LOCK.RECORD (5), user help talks about "semaphore". lame information. Needed is the file name, record id, and the application of the lock. What you get is a file handle and a record key. What I have figured out by theory and trial and error is the following... You can not or I have not figured out how to do it... is to work with RTP36 (lock processor). i can not pass or get information from this program. It would be the easiest to modify this program like you would the MSG program. You can not replace RTP36 Like you would do MSG because the system will crash. OK given that I looked at the LOCK statement and realized that it has three bits of information it probably passes to RTP36. The file var, file key, and the lock type. I also realized that RTP36 must use a common variable to keep track of record locks since if the record is locked already then it does not call a MFS. If so then it is most likely that element 0 of the common variable is not used. If that is true then all that is needed ts to update the element 0 of the common variable at the proper location with @STATION. Given all that, if my theory is correct then there are two ways to solve this... 1) Revelation does a 2 line modification to RPT36 something like this... COMMON_VAR(0) = @STATION at time of lock. @ANS = COMMON_VAR(0) at time it is found that record is already locked. then we could use LOCK FILE_VAR, RECORD_KEY ELSE MESSAGE = 'Record locked by ':QUOTE(@ANS) END Oh so simple! I mean I did all the thinking for you (unless I am wrong, and I doubt I am). The second solution would be to just let us know the common variable name and element count, then we could change element 0 ourselves. again oh so simple! I do not think it is so secret or a source code risk to let us know the common variable name. Otherwise I will just have to use the programming I did in a custom MFS to duplicate the lock process. [url=https://revelation.wiki/doku.php?id=programming:programmers_reference_manual:rti_lock_owner]Would this be what you are looking for[/url] ---- === At 28 FEB 2024 09:24PM Barry Stevens wrote: === Post removed by author [[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=BC9C52253102644EB44E77B21218F7A3|View this thread on the forum...]]