Re: SQL or not?

On 18 Dec 2012 08:03, Keith McCully wrote:

The following SQL worked fine:

INSERT INTO FileA
( SGAICD, SGFWTZ, SGFXTZ, SGUPCZ, SGEPVN, SGC7DT
, SGATTM, SGEQVN, SGOENB, SGERVN, SGDSDZ
, SGABTM, SGESVN, SGOFNB)
SELECT
SGAICD, SGFWTZ, SGFXTZ, SGUPCZ, SGEPVN, '2012-12-17'
, 000000, ' ' , 000000, ' ' , '2012-12-17'
, 000000, ' ' , 000000
FROM FileB
10678 rows inserted ........

So Target fields must be included in the INSERT part to match the
default VALUES

Also, CPYF *MAP does work with dates getting defaulted to run date.
The failure from yesterday was caused by separate error and not
connected with default values.

If the "run date" is the desirable effect, using the CURRENT DATE special register instead of the literal\constant value [i.e. instead of '2012-12-17' shown in the quoted SQL] may be preferable.

I understand that the inquiry is effectively answered, but I offer...

I know a prior message said the columns were not null capable, but having used the term "file" versus "TABLE", I wonder if perhaps DDS had defined the database *FILE named FileA. If so, then all fields\columns have an implicit data-type default value, for when DFT() had not been specified explicitly; i.e. DDS does not support the equivalent of the SQL column definition attribute specification of NOT NULL, DDS only supports the equivalent to NOT NULL WITH DEFAULT. Thus [if DDS then] likely the omission of those DATE data type fields [DDS "L" type] from the column-list on the TABLE named on the INSERT statement should also be an option. And if each of the other columns have the corresponding blank or zero values as data-type [implied] defaults or explicitly those defaults, then those columns can be omitted as well.

So I wonder, [if DDS then] did the statement offered originally be Charles, not effect the desired results? That would have been, effectively, the much more succinct SQL request:

INSERT INTO FileA
( SGAICD, SGFWTZ, SGFXTZ, SGUPCZ, SGEPVN )
SELECT
SGAICD, SGFWTZ, SGFXTZ, SGUPCZ, SGEPVN
FROM FileB