|
Buck That's (compare a copy) the exact approach I am trying to use. I am trying to help a "chain(lock)" programmer grasp the SQL "campare" concept. Obviouly, the concept is aplicable to record level access as well as SQL. Kyle On Tue, 1 Mar 2005 10:40:34 -0500, Buck Calabro <kc2hiz@xxxxxxxxx> wrote: > > I'm struggling upstream against the > > traditional record level access > > idea of locking the record until > > the update is done. > > Well, as an old timer I can tell you that there is absolutely nothing > traditional about locking the record while it's displayed on the > screen. All of my employers considered this practice very primitive. > > To be fair, it solves a lot of programming problems, but is makes it > incredibly difficult to work on sophisticated modern projects. > Programming shouldn't be about making the programmer's life easier - > it should be about making the user's life easier. Solving a business > problem. > > I think I can speak for many traditionalists when I say that there are > two classic solutions to the record locking dillema. One is to have a > flag within the record that the application checks to see if the > record is in use. The other is to compare the record contents to a > saved copy prior to the update. That is: > > chain (no lock) > save copy of record > exfmt > chain (lock) > compare saved+changes to DB copy > different: tell user > same: update DB > > Hope this helps > --buck > _______________________________________________ > This is the RPGNext Discussion and Information (RPGNext) mailing list > To post a message email: RPGNext@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/rpgnext > or email: RPGNext-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpgnext. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.