Rarely happens that two people are updating the same info. So upset users are not the norm. And if this happens to someone, they get a quick realization that updating part of a screen and going to the bathroom part way through has consequences.
Most screen usage of existing records is to look at something and not to update. Sure you can write inquiry screens, but users still get in to update screens and go to lunch. -----Original Message----- From: Richard Taylor [mailto:[EMAIL PROTECTED] Sent: Friday, September 30, 2005 11:02 AM To: [email protected] Subject: RE: [U2] Lock Management (was part of 'Good Programming Practice' ) Well, there may be situations where this would be an acceptable practice. For most general maintenance screens and functions I would not do this. You will not have happy users if they spend an hour entering a large purchase order only to find that someone else has modified a file that is to be update while they were working. Yes, you could do some work to code around that, but why? If you are going to update a record (and the update is a replace and not adding to a statistics file) then you should lock the record as soon as possible and keep it locked until you write it. Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. "The more they complicate the plumbing the easier it is to stop up the drain" - Montgomery Scott NCC-1701 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of Baakkonen, Rodney > Sent: Friday, September 30, 2005 11:14 AM > To: '[email protected]' > Subject: RE: [U2] Lock Management (was part of 'Good Programming > Practice' ) > > How about not locking records until you really are going to write > them. I worked in several places where this was done. There was a concept > of > before and after images. At a user request for update, the record was > reread > setting the lock. At this point the program was aware of the before image > (prior to this user updating anything), the after image (what the current > user had updated) and the current image (the locked record from the data > base). These three images of the record were compared to see if anybody > else > had updated the same fields the current user was updating. If not, the > record was written to the data base. If conflicts were found, the current > user was notified that someone else had updated this record, and their > changes would have to be redone. > > One other complication is if there are many writes associated with a > transaction. You either have to use transaction logging/journaling to > commit/rollback the transaction, have a loop to read/lock all the records > before updating anything for the current screen, or have a home grown > process to roll back the before images. The place where I used this > concept > the most was in the early 80's before TRANSACTION.START and > TRANSACTION.COMMIT were around. So we had a home grown commit/rollback > system. It worked well for a now defunct Pick Billing application from > around 1985 to 1999. (Year 2000 scared the last company into converting). ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
