Re: 5250 and un-do

[Henrik Rützou <hr@xxxxxxxxxxxx>]

Nathan,

well my method gets even more relevant when you start to maintain records
from a browser that all
uses the same REST/CRUD service - the service can't possibly hold any
"data" from a single user
in the air since the service is used by many in a completely random way..

This is of course if you run your webservices stateless that is the defacto
standard in most (99,9999%)
of the worlds web-systems.

Here you just pass the record counter to the browser in a hidden field
where the counter represents the
orgininal "version" of the data so the REST/CRUD service rejects the update
request if it has changed.

On Tue, Dec 19, 2017 at 7:39 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

> Just to follow up on some of the comments so far. Good points all around
> regarding database normalization.
>
> I've never found any use for locking a record while it is displayed, given
> a multi-user environment. I shake my head in awe.
>
> I like Henrik's idea of including an update counter in a record, and
> checking to see if it has changed since the current user last read the
> record. That's more efficient and easier to implement than comparing
> multiple record buffers in memory, each containing a copy of a record in a
> different state.
>
> For applications that are only required to update say one column in a row,
> you end up needing a record buffer on the update operation that is
> distinguished from the record buffer used in the read-from-screen
> operation. Use an assignment statement to copy a column value from one
> buffer to the other. An SQL Update statement does that, under the covers.
>
> Though it would be possible, I wouldn't expect a super-basic utility like
> DFU to have an undo key. Use cases for undo fall in the realm of
> application development.
> --
> This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
> mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/rpg400-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
>
> Help support midrange.com by shopping at amazon.com with our affiliate
> link: http://amzn.to/2dEadiD