× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



On 17 December 2012 23:59, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 17 Dec 2012 16:13, Keith McCully wrote:
Actually, I tried CPYF *MAP first of all. Got a message complaining
that the number of fields didn't match between the files.

Does CPYF *MAP only work if ALL fields in the TO file get populated
from the FROM file? I believe it's okay to have additional fields in
FROM file that are not in the TO file but those could be removed
using the *DROP option.

The CPYF FMTOPT(*MAP) does indeed require that all fields in the
TOFILE exist in the FROMFILE. The CPYF FMTOPT(*NONE) does too, but also
requires the formats are effectively identical [see parameter help text
for the special value *NONE] such that no "mapping" is required between
the fields of the same name.

To effect both mapping *and* ignoring any /extra/ fields in the
FROMFILE [into which no field exists for the data to be mapped], include
the *DROP special value along with the *MAP special value on the Format
Option (FMTOPT) parameter [which allows multiple, compatible, element
specifications]; i.e. use:
CPYF FMTOPT(*MAP *DROP)

Unfortunately [in v5r3 anyhow] the CPF2965 does not allude to the
above combination of special values as an additional possibility for
recovery; i.e. suggesting only that recovery would be possible
specifying either "FMTOPT(*DROP) or FMTOPT(*NOCHK)" :-(

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.