Re: CPYFRMIMPF and extra columns

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

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.

Ah, the original description of the problem wasn't quite as detailed. I
don't have this issue on 7.1 and can't recall experiencing it on 5.4 but
personal memory can be fickle. Perhaps a snippet of the data, the table
description and the non-working CPYFRMIMPF command would trigger an
'aha!' in someone's memory.

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

RFC 4180 fails to define either the CSV format or how CSV files ought to
be treated when importing to a relational table with excess columns.

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

If it's in your wheelhouse, by all means use .NET and directly update
DB2 from there. My .NET colleague here is quite pleased with the high
level of interoperability between DB2 for i and .NET.

I'm not a fan of CPYFRMIMPF myself; general purpose utilities always
have some shortcoming - and that shortcoming seems to arise at an
inopportune moment all too often. I use CPYFRMIMP as a proof of concept
and once I have the skeleton of the process in place I write my own code
to make it more business-friendly.

For instance, what does one want to do with CSV rows that are improperly
escaped and fail CPYFRMIMPF? Print an exception report? Send an email
with the failing rows? Skip the bad field and keep going? Abort the
entire process because it should be all or nothing? With a general
purpose utility, one can't easily make decisions 'as it happens' so to
speak.
--buck