× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Sorry I use K.I.S.S. and that means that every logical file includes all
fields in the PF they are build upon
and btw, for what purpose would one change the address through a logical
file without any other information
that the PF key, it simply dosn't make sense so it is a theoretical
situation just designed to overcomplicate things.

On Tue, Dec 19, 2017 at 3:41 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 12/18/2017 3:12 PM, Booth Martin wrote:

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.
Henrik has good advice regarding making the database more normalised.
It /is/ good advice, but that doesn't really address the primary
conceptual difficulty implementing an undo function in RPG: Unit Record
I/O. Let's assume for the sake of discussion that FIELDA and FIELDB are
ADDRESS and CITY, and thus are both natural attributes of CUSTOMER.

For just a moment, imagine a hypothetical design where you've build a
dozen, a hundred logical files; each one nothing more than the key and
one field. So there's ADDRESSLF, CITYLF and so on. Now, when you
update ADDRESS, you do so through the LF, and there are no stale CITY
contents to accidentally get updated along with ADDRESS.

I know, you're already saying that's way too much work. But once you've
seen that it is possible to design one architecture where the 'stale
record' problem simply doesn't exist, you are free to consider other
possible architectures.

One possibility is keyword:value. Imagine queuing up your changes not
by trying to store an array of records, but by storing keyword:value
sets. If the user changes ADDRESS from 123 Main St to 1325 Congress St,
then you could store the following in your 'transaction' array:

ADDRESS:123 Main St:1325 Congress St

You could use dynamic SQL to ultimately execute the database update
because SQL can do

UPDATE CUSTOMER SET ADDRESS = '1325 Congress St';

...and not disturb CITY, which a different process (address
standardisation) might be changing from Rotterdam to Schenectady for
this customer's address.

The point of this post isn't to propose THE answer, but to propose that
our limiting factor toward 'progress' (whatever that may be) is Unit
Record I/O.

I'm quite certain that the immediate reaction by many is going to be
'the performance will be terrible!' I would suggest that without a
more... concrete model to work with, such a conclusion would be
premature. If we're talking about a spreadsheet-like application where
there are a few hundred of these undo-able changes, will the performance
difference really be all that noticeable to the end user?

--
--buck

http://wiki.midrange.com
Your updates make it better!

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





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.