Re: [U2] [UV] Shared Record Locks
Hi Tom, READL is useful. Normatively, DBMS theory says you should lock *everything* during a process to guarantee that other processes aren't making changes to the db underneath your process. In practice, I've seen a lot of code which doesn't do this. Most of these systems must simply get away with it through sheer dumb luck. Looking at the standard read mechanism; Consider two sessions (pid 101 102) running on a U2 database both READ a customer record, X at the same time (without locking). Both processes update a comments field; both processes write X back to file. (101 reads X, 102 reads X, 101 changes X, 102 changes X, 101 writes X, 102 writes X.) In the scenario above the comments added by 101 are lost because 102 overwrites the changes made by 101. This is an obvious problem with concurrent use of a DB. To fix this you use pessimistic locking and an update lock, READU. This will ensure that if 101 and 102 both try to READU the record, the second process will fail (hopefully gracefully). All good. Now what if the user also needs to read (and not update) a shared parameter item? For example, a spot currency conversion rate. Consider if your process (101) reads, without locking, a rate, while another (102) updates it; you do some processing with the old rate, writes some files, calls a subroutine that re-reads the rate that has just been written by 102 and then does some calculations and writes to some more files - the db could now be inconsistent with figures calculated against both the old and new rate. (101 reads rate, 102 reads rate, 102 changes rate, 102 writes rate, 101 calculates partly based on old rate and new rate). If you (101) were to use READU it would stop other processes from updating the rate while you were doing your calculation but also any other processes which needed to just read the rate record (because they would also be using READU). That could get annoying for users! This is where READL is useful, as it allows a shared lock to be set - ensuring that the record can't change while your (or any other) process has a shared lock on it but allowing the record to be read by any number of processes. The updating process would have to wait till it could get a READU before changing the data. If you use BEGIN/END TRANSACTION in a program then within the transaction boundary best practice locking is enforced. Transactions have to guarantee consistency (ACID), so that you can roll back a set of updates and leave the database in exactly the state it was in at the beginning of the transaction. In this case using READU and READL are mandatory. Hope that helps. Cheers, Stuart -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tom Whitmore Sent: Wednesday, 1 September 2010 11:51 To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Hi, The READL is one verb that causes a lot of confusion, and I have not found a use for it. READU prevents another person to lock the record, but regular READs continue to work without a problem. READL permits multiple READL or READ but no READUs/WRITES are permitted. You cannot update with a READL, because WRITES require a record lock. As I said, I don't understand why anyone would use it. Tom RATEX Business Solutions. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble Sent: Tuesday, August 31, 2010 7:07 PM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] [UV] Shared Record Locks When you have data you want to update, but do not want to prevent people from viewing the rest of the data. I.E. Updating patient information for the next insurance enrollment period, and still letting customer service reps access the data to help customers. HTH -Dan - Original Message - From: u2-users-boun...@listserver.u2ug.org u2-users-boun...@listserver.u2ug.org To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue Aug 31 15:34:51 2010 Subject: [U2] [UV] Shared Record Locks Has anyone a real-world application where UniVerse shared record locks are used? I'm struggling with when they would be preferable to using an update record lock. Anyone willing to share their experiences? Thanks. Perry Taylor ZirMed 626 West Main St , 6th Floor Louisville, KY 40202 www.zirmed.com http://www.zirmed.com/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact
Re: [U2] [UV] Shared Record Locks
Hi Stuart, you are talking about READU not READL. Of course it is dangerous to allow a user to read a record without locking it if that user can then write that record back. But READL will not allow any user to WRITE, not even the holder of the lock unless all locks have been released. OTOH it is contrary to your statement quite useful not to lock everything during a process when no update will occur. Why lock the customer master record for instance if it is only read to display the name and address on a screen? And even your example with the exchange rate doesn't really make sense. If you want to make sure the exchange rate doesn't change then you read it once and assign the value to a variable. Especially on large systems locking the exchange rate record of a popular currency every time somebody reads it can cause serious problems. And no, I don't think this would be a good application for READL, since you only can update the exchange rate once all locks have been released. Imagine you have 1000 or more users and the poor person trying to update exchange rates has to wait until everybody who uses a process that uses this rate to release their locks. Mecki On 01/09/2010 07:25, Boydell, Stuart wrote: Hi Tom, READL is useful. Normatively, DBMS theory says you should lock *everything* during a process to guarantee that other processes aren't making changes to the db underneath your process. In practice, I've seen a lot of code which doesn't do this. Most of these systems must simply get away with it through sheer dumb luck. Looking at the standard read mechanism; Consider two sessions (pid 101 102) running on a U2 database both READ a customer record, X at the same time (without locking). Both processes update a comments field; both processes write X back to file. (101 reads X, 102 reads X, 101 changes X, 102 changes X, 101 writes X, 102 writes X.) In the scenario above the comments added by 101 are lost because 102 overwrites the changes made by 101. This is an obvious problem with concurrent use of a DB. To fix this you use pessimistic locking and an update lock, READU. This will ensure that if 101 and 102 both try to READU the record, the second process will fail (hopefully gracefully). All good. Now what if the user also needs to read (and not update) a shared parameter item? For example, a spot currency conversion rate. Consider if your process (101) reads, without locking, a rate, while another (102) updates it; you do some processing with the old rate, writes some files, calls a subroutine that re-reads the rate that has just been written by 102 and then does some calculations and writes to some more files - the db could now be inconsistent with figures calculated against both the old and new rate. (101 reads rate, 102 reads rate, 102 changes rate, 102 writes rate, 101 calculates partly based on old rate and new rate). If you (101) were to use READU it would stop other processes from updating the rate while you were doing your calculation but also any other processes which needed to just read the rate record (because they would also be using READU). That could get annoying for users! This is where READL is useful, as it allows a shared lock to be set - ensuring that the record can't change while your (or any other) process has a shared lock on it but allowing the record to be read by any number of processes. The updating process would have to wait till it could get a READU before changing the data. If you use BEGIN/END TRANSACTION in a program then within the transaction boundary best practice locking is enforced. Transactions have to guarantee consistency (ACID), so that you can roll back a set of updates and leave the database in exactly the state it was in at the beginning of the transaction. In this case using READU and READL are mandatory. Hope that helps. Cheers, Stuart -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tom Whitmore Sent: Wednesday, 1 September 2010 11:51 To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Hi, The READL is one verb that causes a lot of confusion, and I have not found a use for it. READU prevents another person to lock the record, but regular READs continue to work without a problem. READL permits multiple READL or READ but no READUs/WRITES are permitted. You cannot update with a READL, because WRITES require a record lock. As I said, I don't understand why anyone would use it. Tom RATEX Business Solutions. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble Sent: Tuesday, August 31, 2010 7:07 PM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] [UV] Shared Record Locks When you have data you want to update, but do not want to prevent people from viewing
Re: [U2] [UV] Shared Record Locks
Thanks Mecki! That is what I was trying to relay. The only conceivable reason that I can think of for READL is if you have a process where you want to be able to have more than one person pull up a record, so they could discuss it, and not have the data change between the two reads. In real life, I think there are a lot of ways to handle this situation without using READL. Tom -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Wednesday, September 01, 2010 3:28 AM To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Hi Stuart, you are talking about READU not READL. Of course it is dangerous to allow a user to read a record without locking it if that user can then write that record back. But READL will not allow any user to WRITE, not even the holder of the lock unless all locks have been released. OTOH it is contrary to your statement quite useful not to lock everything during a process when no update will occur. Why lock the customer master record for instance if it is only read to display the name and address on a screen? And even your example with the exchange rate doesn't really make sense. If you want to make sure the exchange rate doesn't change then you read it once and assign the value to a variable. Especially on large systems locking the exchange rate record of a popular currency every time somebody reads it can cause serious problems. And no, I don't think this would be a good application for READL, since you only can update the exchange rate once all locks have been released. Imagine you have 1000 or more users and the poor person trying to update exchange rates has to wait until everybody who uses a process that uses this rate to release their locks. Mecki On 01/09/2010 07:25, Boydell, Stuart wrote: Hi Tom, READL is useful. Normatively, DBMS theory says you should lock *everything* during a process to guarantee that other processes aren't making changes to the db underneath your process. In practice, I've seen a lot of code which doesn't do this. Most of these systems must simply get away with it through sheer dumb luck. Looking at the standard read mechanism; Consider two sessions (pid 101 102) running on a U2 database both READ a customer record, X at the same time (without locking). Both processes update a comments field; both processes write X back to file. (101 reads X, 102 reads X, 101 changes X, 102 changes X, 101 writes X, 102 writes X.) In the scenario above the comments added by 101 are lost because 102 overwrites the changes made by 101. This is an obvious problem with concurrent use of a DB. To fix this you use pessimistic locking and an update lock, READU. This will ensure that if 101 and 102 both try to READU the record, the second process will fail (hopefully gracefully). All good. Now what if the user also needs to read (and not update) a shared parameter item? For example, a spot currency conversion rate. Consider if your process (101) reads, without locking, a rate, while another (102) updates it; you do some processing with the old rate, writes some files, calls a subroutine that re-reads the rate that has just been written by 102 and then does some calculations and writes to some more files - the db could now be inconsistent with figures calculated against both the old and new rate. (101 reads rate, 102 reads rate, 102 changes rate, 102 writes rate, 101 calculates partly based on old rate and new rate). If you (101) were to use READU it would stop other processes from updating the rate while you were doing your calculation but also any other processes which needed to just read the rate record (because they would also be using READU). That could get annoying for users! This is where READL is useful, as it allows a shared lock to be set - ensuring that the record can't change while your (or any other) process has a shared lock on it but allowing the record to be read by any number of processes. The updating process would have to wait till it could get a READU before changing the data. If you use BEGIN/END TRANSACTION in a program then within the transaction boundary best practice locking is enforced. Transactions have to guarantee consistency (ACID), so that you can roll back a set of updates and leave the database in exactly the state it was in at the beginning of the transaction. In this case using READU and READL are mandatory. Hope that helps. Cheers, Stuart -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tom Whitmore Sent: Wednesday, 1 September 2010 11:51 To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Hi, The READL is one verb that causes a lot of confusion, and I have not found a use for it. READU prevents another person to lock the record, but regular
Re: [U2] [UV] Shared Record Locks
I wrote the following little sub... I guess that it works. --Bill SUBROUTINE SUB.LOCK.AND.WRITE.R2 ( R.This, This.File, Record.ID ) prompt '' open This.File to F.This.File else gosub Error.Opening.File gosub Lock.And.Write goThe.End *- *- Lock.And.Write: Lock.Test = recordlocked (F.This.File, Record.ID) begin case case Lock.Test = 0 ;recordlocku F.This.File, Record.ID write R.This on F.This.File, Record.ID release F.This.File, Record.ID case 1; gosub Error.Record.Locking end case return *-- Error.Opening.File: crt @(-1) crt @(-5) crt crt crt crt crt crt crt crt crt crt crt crt ' Big Problem...' : @(-6) crt crt ' _ ' crt ' \\ ' : This.File crt ' \ Error Opening File \' crt ' \\Contact HK.IT ' crt ' [X] ' crt '' : input Ans, 1 Ans = upcase(Ans) begin case case Ans = 'X' ; null case 1 ; go Error.Opening.File end case return to The.End *-- Error.Record.Locking: crt @(-1) crt @(-5) crt crt crt crt crt crt crt crt crt crt ' Big Problem...' : @(-6) crt crt ' _ ' crt ' \\ ' : This.File crt ' \ Error, Record Lock \' crt ' \\Contact HK.IT ' crt crt ' Open New Gull Session, Try UNLOCK.ME ' crt ' [X] ' crt ' ' : input Ans, 1 Ans = upcase(Ans) begin case case Ans = 'X' ; null case 1 ; go Error.Record.Locking end case return to The.End *-- The.End: RETURN END -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor Sent: Tuesday, August 31, 2010 3:35 PM To: U2 Users List Subject: [U2] [UV] Shared Record Locks Has anyone a real-world application where UniVerse shared record locks are used? I'm struggling with when they would be preferable to using an update record lock. Anyone willing to share their experiences? Thanks. Perry Taylor ZirMed 626 West Main St , 6th Floor Louisville, KY 40202 www.zirmed.com http://www.zirmed.com/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Shared Record Locks
READL can be useful when there is a need to maintain a consistent view of master-detail or a set of records related in a tree structure. Putting a READL lock on the master or root record will guarantee a consistent tree during the reading of the detail or nodes, assuming that a READU is taken on the root prior to updating any detail record within the tree. Rick Nuckolls Lynden Inc On Sep 1, 2010, at 5:20 AM, Tom Whitmore wrote: Thanks Mecki! That is what I was trying to relay. The only conceivable reason that I can think of for READL is if you have a process where you want to be able to have more than one person pull up a record, so they could discuss it, and not have the data change between the two reads. In real life, I think there are a lot of ways to handle this situation without using READL. Tom -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Wednesday, September 01, 2010 3:28 AM To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Hi Stuart, you are talking about READU not READL. Of course it is dangerous to allow a user to read a record without locking it if that user can then write that record back. But READL will not allow any user to WRITE, not even the holder of the lock unless all locks have been released. OTOH it is contrary to your statement quite useful not to lock everything during a process when no update will occur. Why lock the customer master record for instance if it is only read to display the name and address on a screen? And even your example with the exchange rate doesn't really make sense. If you want to make sure the exchange rate doesn't change then you read it once and assign the value to a variable. Especially on large systems locking the exchange rate record of a popular currency every time somebody reads it can cause serious problems. And no, I don't think this would be a good application for READL, since you only can update the exchange rate once all locks have been released. Imagine you have 1000 or more users and the poor person trying to update exchange rates has to wait until everybody who uses a process that uses this rate to release their locks. Mecki On 01/09/2010 07:25, Boydell, Stuart wrote: Hi Tom, READL is useful. Normatively, DBMS theory says you should lock *everything* during a process to guarantee that other processes aren't making changes to the db underneath your process. In practice, I've seen a lot of code which doesn't do this. Most of these systems must simply get away with it through sheer dumb luck. Looking at the standard read mechanism; Consider two sessions (pid 101 102) running on a U2 database both READ a customer record, X at the same time (without locking). Both processes update a comments field; both processes write X back to file. (101 reads X, 102 reads X, 101 changes X, 102 changes X, 101 writes X, 102 writes X.) In the scenario above the comments added by 101 are lost because 102 overwrites the changes made by 101. This is an obvious problem with concurrent use of a DB. To fix this you use pessimistic locking and an update lock, READU. This will ensure that if 101 and 102 both try to READU the record, the second process will fail (hopefully gracefully). All good. Now what if the user also needs to read (and not update) a shared parameter item? For example, a spot currency conversion rate. Consider if your process (101) reads, without locking, a rate, while another (102) updates it; you do some processing with the old rate, writes some files, calls a subroutine that re-reads the rate that has just been written by 102 and then does some calculations and writes to some more files - the db could now be inconsistent with figures calculated against both the old and new rate. (101 reads rate, 102 reads rate, 102 changes rate, 102 writes rate, 101 calculates partly based on old rate and new rate). If you (101) were to use READU it would stop other processes from updating the rate while you were doing your calculation but also any other processes which needed to just read the rate record (because they would also be using READU). That could get annoying for users! This is where READL is useful, as it allows a shared lock to be set - ensuring that the record can't change while your (or any other) process has a shared lock on it but allowing the record to be read by any number of processes. The updating process would have to wait till it could get a READU before changing the data. If you use BEGIN/END TRANSACTION in a program then within the transaction boundary best practice locking is enforced. Transactions have to guarantee consistency (ACID), so that you can roll back a set of updates and leave the database in exactly the state it was in at the beginning of the transaction
Re: [U2] [UV] Shared Record Locks
Bill, I thought doing something similar myself when I was a Junior programmer because some people tend to lock records and go for lunch etc.. But what happens if you read the record into the variable R.This do some processing, then the phone rings and you talk for 10 minutes, while somebody else uses the same process, changes the record and writes it back using your subroutine and then you come along and over-write that record once you get off the phone? Not a good idea! If you can update a record I recommend always using READU with the LOCKED clause. What about a loop like this? LOOP READ.OK = 1 READU REC FROM FILE,ID LOCKED READ.OK = 0 ELSE REC = '' UNTIL READ.OK DO * Do some processing if record is locked - like CRT 'Record locked - Try again Y/N? ': INPUT ANSW IF ANSW = 'N' THEN ABORT REPEAT You may even want to write a subroutine to do that if you prefer. You can do some fancy stuff like displaying who's locking the record so the user can ring that person up and tell them to carry on and release the lock. On 01/09/2010 15:30, Bill Brutzman wrote: I wrote the following little sub... I guess that it works. --Bill SUBROUTINE SUB.LOCK.AND.WRITE.R2 ( R.This, This.File, Record.ID ) prompt '' open This.File to F.This.File else gosub Error.Opening.File gosub Lock.And.Write goThe.End *- *- Lock.And.Write: Lock.Test = recordlocked (F.This.File, Record.ID) begin case case Lock.Test = 0 ;recordlocku F.This.File, Record.ID write R.This on F.This.File, Record.ID release F.This.File, Record.ID case 1; gosub Error.Record.Locking end case return *-- Error.Opening.File: crt @(-1) crt @(-5) crt crt crt crt crt crt crt crt crt crt crt crt ' Big Problem...' : @(-6) crt crt ' _ ' crt ' \\ ' : This.File crt ' \ Error Opening File \' crt ' \\Contact HK.IT ' crt ' [X] ' crt '' : input Ans, 1 Ans = upcase(Ans) begin case case Ans = 'X' ; null case 1 ; go Error.Opening.File end case return to The.End *-- Error.Record.Locking: crt @(-1) crt @(-5) crt crt crt crt crt crt crt crt crt crt ' Big Problem...' : @(-6) crt crt ' _ ' crt ' \\ ' : This.File crt ' \ Error, Record Lock \' crt ' \\Contact HK.IT ' crt crt ' Open New Gull Session, Try UNLOCK.ME ' crt ' [X] ' crt ' ' : input Ans, 1 Ans = upcase(Ans) begin case case Ans = 'X' ; null case 1 ; go Error.Record.Locking end case return to The.End *-- The.End: RETURN END -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor Sent: Tuesday, August 31, 2010 3:35 PM To: U2 Users List Subject: [U2] [UV] Shared Record Locks Has anyone a real-world application where UniVerse shared record locks are used? I'm struggling with when they would be preferable to using an update record lock. Anyone willing to share their experiences? Thanks. Perry Taylor ZirMed 626 West Main St , 6th Floor Louisville, KY 40202 www.zirmed.com http://www.zirmed.com/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended
Re: [U2] [UV] Shared Record Locks
Mecki: I guess that a lot of programmers (perhaps most of them) write programs where when editing say a new Customer... address, phone, etc... open a screen and let the end user update the fields and then finish with a grand save... all at once... on all the records (fields) for that customer. Of course, if the server goes down while the user is taking minutes to fill in the screen, the user loses everything for that customer and then has to start over with that customer. I prefer to save the entire record each time a field is changed. Granted, this is a lot more writes to disk but it handles the given problem. If two users are looking at the same data, their screens are updated following each discrete transaction. I do like the given readu technique; I will consider using it. Thanks for writing. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Wednesday, September 01, 2010 1:00 PM To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Bill, I thought doing something similar myself when I was a Junior programmer because some people tend to lock records and go for lunch etc.. But what happens if you read the record into the variable R.This do some processing, then the phone rings and you talk for 10 minutes, while somebody else uses the same process, changes the record and writes it back using your subroutine and then you come along and over-write that record once you get off the phone? Not a good idea! If you can update a record I recommend always using READU with the LOCKED clause. What about a loop like this? LOOP READ.OK = 1 READU REC FROM FILE,ID LOCKED READ.OK = 0 ELSE REC = '' UNTIL READ.OK DO * Do some processing if record is locked - like CRT 'Record locked - Try again Y/N? ': INPUT ANSW IF ANSW = 'N' THEN ABORT REPEAT You may even want to write a subroutine to do that if you prefer. You can do some fancy stuff like displaying who's locking the record so the user can ring that person up and tell them to carry on and release the lock. On 01/09/2010 15:30, Bill Brutzman wrote: I wrote the following little sub... I guess that it works. --Bill SUBROUTINE SUB.LOCK.AND.WRITE.R2 ( R.This, This.File, Record.ID ) prompt '' open This.File to F.This.File else gosub Error.Opening.File gosub Lock.And.Write goThe.End *- *- Lock.And.Write: Lock.Test = recordlocked (F.This.File, Record.ID) begin case case Lock.Test = 0 ;recordlocku F.This.File, Record.ID write R.This on F.This.File, Record.ID release F.This.File, Record.ID case 1; gosub Error.Record.Locking end case return *- - Error.Opening.File: crt @(-1) crt @(-5) crt crt crt crt crt crt crt crt crt crt crt crt ' Big Problem...' : @(-6) crt crt ' _ ' crt ' \\ ' : This.File crt ' \ Error Opening File \' crt ' \\Contact HK.IT ' crt ' [X] ' crt '' : input Ans, 1 Ans = upcase(Ans) begin case case Ans = 'X' ; null case 1 ; go Error.Opening.File end case return to The.End *- - Error.Record.Locking: crt @(-1) crt @(-5) crt crt crt crt crt crt crt crt crt crt ' Big Problem...' : @(-6) crt crt ' _ ' crt ' \\ ' : This.File crt ' \ Error, Record Lock \' crt ' \\Contact HK.IT ' crt crt ' Open New Gull Session, Try UNLOCK.ME ' crt ' [X] ' crt ' ' : input Ans, 1 Ans = upcase(Ans) begin case case Ans = 'X' ; null case 1 ; go Error.Record.Locking end case return to The.End *- - The.End: RETURN END -Original
Re: [U2] [UV] Shared Record Locks
Bill, How do you handle mandatory fields with your technique? What guarantees that a user doesn't just kill a session before all input is done to cheat the system? And that is in my experience much more likely than a server crash. There probably is a very good reason why nearly every programmer prefers the grand save when input is complete. I rather have no record at all than corrupted data due to missing mandatory fields. And the idea of multiple users manipulating the same record simultaneously makes me feel very uncomfortable. Mecki On 01/09/2010 18:58, Bill Brutzman wrote: Mecki: I guess that a lot of programmers (perhaps most of them) write programs where when editing say a new Customer... address, phone, etc... open a screen and let the end user update the fields and then finish with a grand save... all at once... on all the records (fields) for that customer. Of course, if the server goes down while the user is taking minutes to fill in the screen, the user loses everything for that customer and then has to start over with that customer. I prefer to save the entire record each time a field is changed. Granted, this is a lot more writes to disk but it handles the given problem. If two users are looking at the same data, their screens are updated following each discrete transaction. I do like the given readu technique; I will consider using it. Thanks for writing. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Wednesday, September 01, 2010 1:00 PM To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Bill, I thought doing something similar myself when I was a Junior programmer because some people tend to lock records and go for lunch etc.. But what happens if you read the record into the variable R.This do some processing, then the phone rings and you talk for 10 minutes, while somebody else uses the same process, changes the record and writes it back using your subroutine and then you come along and over-write that record once you get off the phone? Not a good idea! If you can update a record I recommend always using READU with the LOCKED clause. What about a loop like this? LOOP READ.OK = 1 READU REC FROM FILE,ID LOCKED READ.OK = 0 ELSE REC = '' UNTIL READ.OK DO * Do some processing if record is locked - like CRT 'Record locked - Try again Y/N? ': INPUT ANSW IF ANSW = 'N' THEN ABORT REPEAT You may even want to write a subroutine to do that if you prefer. You can do some fancy stuff like displaying who's locking the record so the user can ring that person up and tell them to carry on and release the lock. On 01/09/2010 15:30, Bill Brutzman wrote: I wrote the following little sub... I guess that it works. --Bill SUBROUTINE SUB.LOCK.AND.WRITE.R2 ( R.This, This.File, Record.ID ) prompt '' open This.File to F.This.File else gosub Error.Opening.File gosub Lock.And.Write goThe.End *- *- Lock.And.Write: Lock.Test = recordlocked (F.This.File, Record.ID) begin case case Lock.Test = 0 ;recordlocku F.This.File, Record.ID write R.This on F.This.File, Record.ID release F.This.File, Record.ID case 1; gosub Error.Record.Locking end case return *- - Error.Opening.File: crt @(-1) crt @(-5) crt crt crt crt crt crt crt crt crt crt crt crt ' Big Problem...' : @(-6) crt crt ' _ ' crt ' \\ ' : This.File crt ' \ Error Opening File \' crt ' \\Contact HK.IT ' crt ' [X] ' crt '' : input Ans, 1 Ans = upcase(Ans) begin case case Ans = 'X' ; null case 1 ; go Error.Opening.File end case return to The.End *- - Error.Record.Locking: crt @(-1) crt @(-5) crt crt crt crt crt crt crt crt crt crt ' Big Problem...' : @(-6) crt crt ' _ ' crt ' \\ ' : This.File crt ' \ Error, Record Lock \' crt
Re: [U2] [UV] Shared Record Locks
Most of our lock code looks almost identical to Mecki's example, but in the lower section of the loop we call a subroutine that parses the output of LIST.READU. The user attempting to acquire the lock is then notified via a PRINTERR message who currently has the lock. We've found this to be invaluable over the years because it allows a user to directly contact the culprit rather than calling I.T. to find out what's going on. It can also reveal personell issues to management. Eg: If a manager frequently gets calls asking Do you know where employee X is? They have a customer locked and they're not at their desk., the manager may be prompted to find out what employee X is doing. We had this very issue not that long ago. It turned out employee X was frequently off doing things other than their job, and was let go. The lock issues went away after that. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Brutzman Sent: Wednesday, September 01, 2010 10:58 AM To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Mecki: I guess that a lot of programmers (perhaps most of them) write programs where when editing say a new Customer... address, phone, etc... open a screen and let the end user update the fields and then finish with a grand save... all at once... on all the records (fields) for that customer. Of course, if the server goes down while the user is taking minutes to fill in the screen, the user loses everything for that customer and then has to start over with that customer. I prefer to save the entire record each time a field is changed. Granted, this is a lot more writes to disk but it handles the given problem. If two users are looking at the same data, their screens are updated following each discrete transaction. I do like the given readu technique; I will consider using it. Thanks for writing. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Wednesday, September 01, 2010 1:00 PM To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Bill, I thought doing something similar myself when I was a Junior programmer because some people tend to lock records and go for lunch etc.. But what happens if you read the record into the variable R.This do some processing, then the phone rings and you talk for 10 minutes, while somebody else uses the same process, changes the record and writes it back using your subroutine and then you come along and over-write that record once you get off the phone? Not a good idea! If you can update a record I recommend always using READU with the LOCKED clause. What about a loop like this? LOOP READ.OK = 1 READU REC FROM FILE,ID LOCKED READ.OK = 0 ELSE REC = '' UNTIL READ.OK DO * Do some processing if record is locked - like CRT 'Record locked - Try again Y/N? ': INPUT ANSW IF ANSW = 'N' THEN ABORT REPEAT You may even want to write a subroutine to do that if you prefer. You can do some fancy stuff like displaying who's locking the record so the user can ring that person up and tell them to carry on and release the lock. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Shared Record Locks
Mecki: 1. Yes, mandatory fields are handled with a grand save here. We have a several LIVE examples of grand saves here. 2. Every time a user changes any field of data, it is saved; there is no way to cheat. 3. Our sever might be down for a half-hour per year. Thus, a strong argument cannot be made (either way) for this functionality. 4. Half of the contact data in a CRM system is better than none. Just because the cell phone field might be blank does not mean that any of the other data is corrupted. 5. In an airline reservation system, end-users' screens need to show fresh real-time data. Passengers and airport check-in clerks cannot wait ten minutes for grand saves. Adobe's new LiveCycle Data Services allows for discrete field updating over the web. 6. While I agree that multiple users manipulating the same record simultaneously is highly problematic, it is important to frame the issue correctly. I like to think of it as real-time interactive record updating. Every second, a fresh read shows the latest. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Wednesday, September 01, 2010 3:34 PM To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Bill, How do you handle mandatory fields with your technique? What guarantees that a user doesn't just kill a session before all input is done to cheat the system? And that is in my experience much more likely than a server crash. There probably is a very good reason why nearly every programmer prefers the grand save when input is complete. I rather have no record at all than corrupted data due to missing mandatory fields. And the idea of multiple users manipulating the same record simultaneously makes me feel very uncomfortable. Mecki On 01/09/2010 18:58, Bill Brutzman wrote: Mecki: I guess that a lot of programmers (perhaps most of them) write programs where when editing say a new Customer... address, phone, etc... open a screen and let the end user update the fields and then finish with a grand save... all at once... on all the records (fields) for that customer. Of course, if the server goes down while the user is taking minutes to fill in the screen, the user loses everything for that customer and then has to start over with that customer. I prefer to save the entire record each time a field is changed. Granted, this is a lot more writes to disk but it handles the given problem. If two users are looking at the same data, their screens are updated following each discrete transaction. I do like the given readu technique; I will consider using it. Thanks for writing. --Bill -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Wednesday, September 01, 2010 1:00 PM To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Bill, I thought doing something similar myself when I was a Junior programmer because some people tend to lock records and go for lunch etc.. But what happens if you read the record into the variable R.This do some processing, then the phone rings and you talk for 10 minutes, while somebody else uses the same process, changes the record and writes it back using your subroutine and then you come along and over-write that record once you get off the phone? Not a good idea! If you can update a record I recommend always using READU with the LOCKED clause. What about a loop like this? LOOP READ.OK = 1 READU REC FROM FILE,ID LOCKED READ.OK = 0 ELSE REC = '' UNTIL READ.OK DO * Do some processing if record is locked - like CRT 'Record locked - Try again Y/N? ': INPUT ANSW IF ANSW = 'N' THEN ABORT REPEAT You may even want to write a subroutine to do that if you prefer. You can do some fancy stuff like displaying who's locking the record so the user can ring that person up and tell them to carry on and release the lock. On 01/09/2010 15:30, Bill Brutzman wrote: I wrote the following little sub... I guess that it works. --Bill SUBROUTINE SUB.LOCK.AND.WRITE.R2 ( R.This, This.File, Record.ID ) prompt '' open This.File to F.This.File else gosub Error.Opening.File gosub Lock.And.Write goThe.End * - * - Lock.And.Write: Lock.Test = recordlocked (F.This.File, Record.ID) begin case case Lock.Test = 0 ;recordlocku F.This.File, Record.ID write R.This on F.This.File, Record.ID release F.This.File, Record.ID case 1; gosub Error.Record.Locking end case return
Re: [U2] [UV] Shared Record Locks {Unclassified}
Dear oh deary me, this is sooo 1970s! Guys, Google 'optimistic locking' [Quick overview: 1) When the user first looks at the data, * read the record, no lock, * save a copy in memory (Named Common) or on a BeforeLook disk file 2) When the user wants to update the record, * read the record with lock * compare the just-read record with the saved copy + if they are the same - write the updates + if they are different - give the user an error message someone else fritzed with it while you were dawdling * throw away the BeforeLook * unlock everything, you're done This is called 'optimistic' because you're betting that the BeforeLook and the current record are almost always the same, so you hardly ever get to take the error path. End of quick and probably oversimplified overview] -Original Message- From: u2-users-boun...@listserver.u2ug.org On Behalf Of Mecki Foerthmann Sent: Thursday, 2 September 2010 5:00 a.m. To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Bill, I thought doing something similar myself when I was a Junior programmer because some people tend to lock records and go for lunch etc.. But what happens if you read the record into the variable R.This do some processing, then the phone rings and you talk for 10 minutes, while somebody else uses the same process, changes the record and writes it [snip] The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Shared Record Locks {Unclassified}
Note that I have had customers who have had conformance requirements (FDA) that
do not allow them to use optimistic locking. It is not appropriate in all
cases.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of HENDERSON MIKE, MR
Sent: Wednesday, September 01, 2010 2:22 PM
To: U2 Users List
Subject: Re: [U2] [UV] Shared Record Locks {Unclassified}
Dear oh deary me, this is sooo 1970s!
Guys, Google 'optimistic locking'
[Quick overview:
1) When the user first looks at the data,
* read the record, no lock,
* save a copy in memory (Named Common) or on a BeforeLook disk file
2) When the user wants to update the record,
* read the record with lock
* compare the just-read record with the saved copy
+ if they are the same
- write the updates
+ if they are different
- give the user an error message
someone else fritzed with it while you were dawdling
* throw away the BeforeLook
* unlock everything, you're done
This is called 'optimistic' because you're betting that the BeforeLook
and the current record are almost always the same, so you hardly ever
get to take the error path.
End of quick and probably oversimplified overview]
-Original Message-
From: u2-users-boun...@listserver.u2ug.org On Behalf Of Mecki
Foerthmann
Sent: Thursday, 2 September 2010 5:00 a.m.
To: U2 Users List
Subject: Re: [U2] [UV] Shared Record Locks
Bill,
I thought doing something similar myself when I was a Junior
programmer
because some people tend to lock records and go for lunch etc..
But what happens if you read the record into the variable R.This do
some
processing, then the phone rings and you talk for 10 minutes, while
somebody else uses the same process, changes the record and writes it
[snip]
The information contained in this Internet Email message is intended
for the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence Force.
If you are not the intended recipient you must not use, disclose, copy or
distribute this message or the information in it.
If you have received this message in error, please Email or telephone
the sender immediately.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Shared Record Locks
On 01/09/10 18:58, Bill Brutzman wrote: Mecki: I guess that a lot of programmers (perhaps most of them) write programs where when editing say a new Customer... address, phone, etc... open a screen and let the end user update the fields and then finish with a grand save... all at once... on all the records (fields) for that customer. Of course, if the server goes down while the user is taking minutes to fill in the screen, the user loses everything for that customer and then has to start over with that customer. Do they? I prefer to save the entire record each time a field is changed. Granted, this is a lot more writes to disk but it handles the given problem. If two users are looking at the same data, their screens are updated following each discrete transaction. I do like the given readu technique; I will consider using it. Thanks for writing. Why not do what a lot of nix programs do - flush the input data to a recovery file. Then, when the data gets flushed with a grand write, wipe the recovery info. You just check, on going into the program, whether a recovery record exists, and take appropriate action. As an aside, when I wrote an accounts program, I got all the data from the user and didn't care that much about the up-to-dateness of the data displayed. What mattered was the amounts to be added/subtracted from the various ledgers. Then when they'd entered all the data and hit commit, only then did I lock the records, REDO all the calculations, and write to file. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Shared Record Locks {Unclassified}
Mike, Sooo 1970s? In the 70s when you encountered a lock your program would just sit there and if you were lucky your terminal would beep until the lock was released. IIRC we didn't even have record locks in those days, just group locks, and READU didn't have a LOCKED clause either. Mecki On 01/09/2010 22:21, HENDERSON MIKE, MR wrote: Dear oh deary me, this is sooo 1970s! Guys, Google 'optimistic locking' [Quick overview: 1) When the user first looks at the data, * read the record, no lock, * save a copy in memory (Named Common) or on a BeforeLook disk file 2) When the user wants to update the record, * read the record with lock * compare the just-read record with the saved copy + if they are the same - write the updates + if they are different - give the user an error message someone else fritzed with it while you were dawdling * throw away the BeforeLook * unlock everything, you're done This is called 'optimistic' because you're betting that the BeforeLook and the current record are almost always the same, so you hardly ever get to take the error path. End of quick and probably oversimplified overview] -Original Message- From: u2-users-boun...@listserver.u2ug.org On Behalf Of Mecki Foerthmann Sent: Thursday, 2 September 2010 5:00 a.m. To: U2 Users List Subject: Re: [U2] [UV] Shared Record Locks Bill, I thought doing something similar myself when I was a Junior programmer because some people tend to lock records and go for lunch etc.. But what happens if you read the record into the variable R.This do some processing, then the phone rings and you talk for 10 minutes, while somebody else uses the same process, changes the record and writes it [snip] The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Shared Record Locks
Hi Mecki, Actually you missed the point. Possibly entirely.. Cheers -Original Message- Hi Stuart, you are talking about READU not READL. Of course [snip] ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] [UV] Shared Record Locks
Has anyone a real-world application where UniVerse shared record locks are used? I'm struggling with when they would be preferable to using an update record lock. Anyone willing to share their experiences? Thanks. Perry Taylor ZirMed 626 West Main St , 6th Floor Louisville, KY 40202 www.zirmed.com http://www.zirmed.com/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Shared Record Locks
I had a process that would spin off multiple phantoms, each putting a shared lock on a control group record. When each child phantom finished, it would release its shared lock. When the main process was able to obtain an update lock, it knew all the child processes had completed and it would close the group. Is that the kind of thing you're asking about? BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor Sent: Tuesday, August 31, 2010 12:35 PM To: U2 Users List Subject: [U2] [UV] Shared Record Locks Has anyone a real-world application where UniVerse shared record locks are used? I'm struggling with when they would be preferable to using an update record lock. Anyone willing to share their experiences? Thanks. Perry Taylor ZirMed 626 West Main St , 6th Floor Louisville, KY 40202 www.zirmed.com http://www.zirmed.com/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Shared Record Locks
When you have data you want to update, but do not want to prevent people from viewing the rest of the data. I.E. Updating patient information for the next insurance enrollment period, and still letting customer service reps access the data to help customers. HTH -Dan - Original Message - From: u2-users-boun...@listserver.u2ug.org u2-users-boun...@listserver.u2ug.org To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue Aug 31 15:34:51 2010 Subject: [U2] [UV] Shared Record Locks Has anyone a real-world application where UniVerse shared record locks are used? I'm struggling with when they would be preferable to using an update record lock. Anyone willing to share their experiences? Thanks. Perry Taylor ZirMed 626 West Main St , 6th Floor Louisville, KY 40202 www.zirmed.com http://www.zirmed.com/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Shared Record Locks
Hi, The READL is one verb that causes a lot of confusion, and I have not found a use for it. READU prevents another person to lock the record, but regular READs continue to work without a problem. READL permits multiple READL or READ but no READUs/WRITES are permitted. You cannot update with a READL, because WRITES require a record lock. As I said, I don't understand why anyone would use it. Tom RATEX Business Solutions. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble Sent: Tuesday, August 31, 2010 7:07 PM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] [UV] Shared Record Locks When you have data you want to update, but do not want to prevent people from viewing the rest of the data. I.E. Updating patient information for the next insurance enrollment period, and still letting customer service reps access the data to help customers. HTH -Dan - Original Message - From: u2-users-boun...@listserver.u2ug.org u2-users-boun...@listserver.u2ug.org To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue Aug 31 15:34:51 2010 Subject: [U2] [UV] Shared Record Locks Has anyone a real-world application where UniVerse shared record locks are used? I'm struggling with when they would be preferable to using an update record lock. Anyone willing to share their experiences? Thanks. Perry Taylor ZirMed 626 West Main St , 6th Floor Louisville, KY 40202 www.zirmed.com http://www.zirmed.com/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
