On 8/17/2017 3:38 PM, Dan wrote:

Why do you consider this a "best practice"?
-snip-
I can see it if it's because of adding columns to a table
in the future

That's why.

-snip-

...but the tables in this application are used only in a
narrow set of programs

'Best practise' is the thing that enables change to come easier and the
outcome more predictable. Fullselect is more fragile than an explicit
column list, making change harder, and success less predictable.

It's OK to deviate from 'best practise' but it should be done with
deliberate intent, not as a rationalisation of a decision made by who
knows who, way back when. That's a lesson that was hard won for me
personally.

and it actually is necessary for them to handle any
added columns automatically.

I live with a system whose roots run deep. Lots and lots of 'load a
scratch file' > 'sort' > 'print'. Of course some of the sorts are
OPNQRYF, QRYDTA, and STRQMQRY, but they are still making copies of the
data. It has become a painful, repeated lesson that every time a copy
is made - even temporarily, just for a few minutes - the copy becomes
out of synch with the original.

It's a diversion, but imagine doing a sort/copy/INSERT INTO from a
customer master file into a copy. That takes a moment or two, and then
we do a copy/sort/INSERT INTO from a child table, say a list of
invoices. Well in the time between those two copies, someone (an EDI
system?) added a customer and an invoice. Now we have a copy of the
invoice but not a copy of the customer master. This is not theoretical,
and it's a real pattern that is only going to become more prevalent as
we move into self-provisioning (ie customers sign themselves up online).
The classic solution to this would be to ALCOBJ all of the parent/child
files in one operation, make the copies, then DLCOBJ but that is a
non-starter in a real time system.

Situations like this have started to smell like VIEWs to me, but I'm not
at all sure that's universal.


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-2019 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].