RE: Why NOT the web?

And only compare fields that you are updating.  If you are only updating 
the contact name in the customer master, then who cares if the balance 
went up.  Just verify that the contact name hasn't changed, and just 
update only that field.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Nathan M. Andelin" <nandel@xxxxxxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
01/03/2005 02:47 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
cc

Subject
RE: Why NOT the web?






> I can see wanting to lock it [a record] if you want
> to display it in a form for update, but not for inquiry.

Or, NOT lock the record until submitted for update.

Keeping a "before image" of the record, and CHAIN(ing) to the "current
image" of the record, would enable the program to implement logic to deal
with records that may have been changed in the mean time by another user 
or
program.  How the program deals with a previously changed record probably
depends on the application.

Write over the top of previous changes?  Redisplay the current record on 
the
screen with a message indicating that another user beat you to the update?

The problem of locking a record before writing it to the screen is that 
you
never know how long the user will retain the lock, which may cause other
programs to abend.  Whether the UI is 5250 based, or browser based, it 
seems
that you're dealing with the same issue.

Nathan.



-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.