Re: 5250 and un-do

Booth

there is no need for a lot of programming her, the simple solution is to
place a "Record Update Counter" on each record.

If tw users reads the record for update the will get the same number, if
the second user updates the record first his
update is allowed and the update counter is increased by on, if the first
user then tries to update the record he is told
that others has updated the record and he has the start over again.

In practise in most cases these collision are rare and not worth to put a
lot of programming into - why should two
user update the same customer at the same time - and what is the chance for
that to happen?

On Mon, Dec 18, 2017 at 7:32 PM, Booth Martin <booth@xxxxxxxxxxxx> wrote:

Make the plan with no protracted locks. That's pretty standard practice
now, thanks to the training you and others provide for us.

I like the idea of an array with before/after image of each change made.
It works even for two users in the same file. If I undo, get the data,
compare it to my after image and it is different then I know another user
changed the data and I need PlanHuh? If the images compare, then make the
data the before image and it's undone.


On 12/18/2017 12:15 PM, Jon Paris wrote:

It also assumes a lock on all objects affected!


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

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