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



Did you try RPLNULLVAL(*FLDDFT)?

I've imported data into BD2 tables that had extra columns not supplied in
the CSV.



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Matt Olson
Sent: Thursday, May 23, 2013 2:38 PM
To: Midrange Systems Technical Discussion
Subject: RE: CPYFRMIMPF and extra columns

It works fine with the table I have now, I can get all the data to import
just fine.

I added column to the file at the very end of the file I am importing
records into, then run the exact same command and instead of 220 records
imported, we just get 0 records imported. No errors.

Kinda missing the TextFieldParser class built in .NET framework which
follows RFC 4180. This would be done in about 10 lines of code.

We'll probably end up rolling our own, or using scott klements code.

Matt

-----Original Message-----
From: Buck Calabro [mailto:kc2hiz@xxxxxxxxx]
Sent: Thursday, May 23, 2013 4:35 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: CPYFRMIMPF and extra columns

On 5/23/2013 5:03 PM, Matt Olson wrote:

It seems CPYFRMIMPF only works if the # of columns matches the number of
commas in the CSV file you are trying to import.

Commas separate fields. If there's one comma, there are two fields. If
your CSV has 25 commas, you need 26 fields defined.

I tried adding extra column at the very end of the destination file that I
want to take the CSV file into, but then it doesn't parse any records.

The job log is somewhat helpful here. You can see which fields aren't
mapping and why. ish.

Is there an option in the CPYFRMIMPF I'm overlooking?

There are lots of options and they all need to match the data you're trying
to import. If none of the input rows converted, I'd guess that the end of
record character is the culprit. If your file is coming from *nix, EOR is
*LF. If coming from Windows, EOR is *CRLF. I've had poor luck with the
default *EOR.

You need to exactly match the string delimiter (usually a double quote but
sometimes nothing at all!) and the field delimiter (usually a comma but
sometimes a tab). If it's a big file and it takes a long time to process,
try FROMRCD(*FIRST 10) or some small number that will get your parameters
tested quickly. Don't forget about RPLNULLVAL - you may need it.
--buck
--
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.

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

Follow-Ups:
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.