Re: 5250 and un-do -- ROW CHANGE TOKEN warning

Well it may seems pretty straight forward to you indicating that you are a
programmer locked-into stateful 5250 RPG because it simply
dosn't work in a stateless environment (even programmed in RPG) or in any
other program languages that hasn't got "datastructures"
the proprietary none objectoriented RPG way.

A REST/CRUD service on a server that is the most common way to communicate
file maintenance between a browser based client
and a server dosn't hold any information from previous call to it, so where
do you expect to store the "before values" in the client?

That means a lot of hidden fields that must reside in the browser since the
REST/CRUD service is unable to store the information.


On Fri, Dec 22, 2017 at 7:47 PM, Booth Martin <booth@xxxxxxxxxxxx> wrote:

Which, of course, is designed to act as a simple way to solve the initial
problem of colliding updates.

The more I follow this thread the more convinced I am that the simplest
solution is to compare the before and after values of the specific field(s)
in question. Its easy, its clear, and it deals with the actual data and
not on some hazy smoke signal from a field far away. Saving the field's
initial value is really not that many lines of code; certainly it is less
than what is apparently involved in getting & setting unique timestamps,
computing micro-seconds, and with having to update micro-seconds.

To compare before & after, I use a variation of either a 3 data structures
defined like the record involved, or if its a record with many fields and I
am interested in just a few fields, a data structure of just the fields I
care about. the 3 data structures are: Original (prefix("Or_)"), the
record, and New prefix("Nw_')).

Then, I read the record, load (Or_) and the screen fields, do the screen
work, load (Nw_) and get the record again and compare for changes. Thats
pretty straight forward and does not concern itself with timestamp fields,
or with false positives (a different field was changed at another work
station).


On 12/22/2017 7:43 AM, Raul Jager wrote:

The initial reason to suggest row change is to know if the row has
changed between the time it was read to display and the time it is read
to update.

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