× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.