Re: How to "omit" a GENERATED ALWAYS column on an Insert that doesn't use VALUES()?

On 8/17/2017 4:30 PM, Dan wrote:

As I reviewed the handful of our production applications that use embedded
SQL, I realized that they do use the VALUES form. The pattern I noticed is
that the query only selected a few fields from a table that had a hundred
or more fields defined. It obviously makes the programming easier if you
don't need to define the receiving data structure with fields that won't be
used,

The Aha! moment for me was when I realised that writing up a list of the
columns that were Actually Going To Be Needed (tm) wasn't as much a
chore today as was figuring out which of a dozen SELECT * columns were
being not used a year in the future :-( Change is easier when I can say
for sure that LAST_PURCHASE_DATE really isn't used in this program, so I
can pull it from MASTER and put it in TRANSACTION without worrying about
that change breaking this program.

and clarifies for the next developer what fields are actually being
used.

Bingo.

In my particular application, this is an archival utility where we send
journal extracts to another non-i system. So, if someone adds a new field
to a table, my application needs to pick up that new field right from the
get-go. We can't rely on instructions we might place in a PF DDS source
that says, hey, if you change anything here, make the same changes in the
select statement in application ARCHIVEXYZ.

In addition, ARCHIVEXYZ currently does this for 33 tables, so manually
spec'ing all the fields in the select statement would be an arduous task.

Write code that generates the column list for you. SYSCOLUMNS knows
what's what.