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: [email protected] [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] 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 [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
