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 >> >> go The.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 >> > _______________________________________________ > 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
