Re: 5250 and un-do

This is a matter of simple DB design, you should NEVER have tables where
some fields may be updated by users maintenance programs and at the same
time have fields that processes (batch) may update - it is a simple as that
- dont have a item-description in the same table at qty on stock - bad
design!

If you devide the tables into that the fieldA/fieldB scenario will not
occur since the processes (batch) will read the record with lock, update
fields and update the record - any other process will wait unitl it is done.
If you have "sets" like orderheader/order lines you start locking the
header and processes the details and unlock the header - if another process
wants to do the same it will wait for the first process to finish.

Don't ansk me what happens if the first process goes into a halt - the
answer is - then whoever made it is a lousy programmer!

To the scenario where one user wants to update fieldA while another updates
fieldB it can of course be programmed but - since it extremly rarly occurs
it is a waste of time to try to allow it and it will just complicate the
program making the program harder to maintain. It's simply in most cases
not worth the effort or cost and IMHO only suited for stubborn theoretical
discussions like what is fastest and gives the smallest footprint if you
want a field to be zero ...

fieldA = fieldA - fieldA; // yes, I saved one constant, does anybody
know if I also saved some disk and storage footprint?
fieldA= 0;



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

I am not sure how to respond, or even if respond. But that has yet to
stop me. :)

if my process changes FieldB and during that process another process has
changed FieldA then using a record-updated counter has no relevance. My
update to FieldB is still appropriate.

I agree that these collisions are rare, but they happen and if not
handled, they are ugly. Really ugly.


On 12/18/2017 12:45 PM, Henrik Rützou wrote:

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?

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