Re: SQL insert error - value for column too long

Because (as per previous responses) it's a positional operation, it's not
copied by name.

On Wed, May 29, 2019 at 9:36 AM Steve Richter <stephenrichter@xxxxxxxxx>
wrote:

ok, that is sure good to know. Why SQL would implicitly copy from one
column name to a different column name is something I do not understand.


On Tue, May 28, 2019 at 4:46 PM John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Tue, May 28, 2019 at 2:05 PM Robert Rogerson <rogersonra@xxxxxxxxx>
wrote:

As Rob and Joe pointed out the columns must be in the same positions.
To get this to work with in INSERT statement you would have to list all

the

columns.
INSERT INTO wlklib/dshpf34 COLUMNS(col1, col2, ...)
( select a.* from DSHXFR/DSHPF34 a )
make the order of the columns in dshpf34 match the column order of
dshxfr/dshpf34.

More specifically, Steve needs to keep in mind that SELECT simply
returns a list of values for each row. Those values have no names
associated with them. So the columns specified in the COLUMNS portion
of the INSERT statement have to appear in the same order that they are
defined in DSHXFR/DSHPF34.

Alternatively you could use a CPYF with FmtOpt(*MAP *DRP) and this

should

popule correctly

This is much simpler, though not as flexible (SQL lets you easily
filter or sort, for example).

John Y.
--

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com