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

On Thu, Aug 17, 2017 at 4:05 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

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

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, and clarifies for the next developer what fields are actually being
used.

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.

- Dan