Re: CPYTOIMPF - extra delimiter issue

Blake.Moorcroft wrote:

Has anyone ever run into an issue when building a CSV file from a DB2 table (created with SQL create statement), where an extra string delimiter appears in the first column of the csv file.

We are producing a csv file for automatic distribution to a client.
The data base file is populated using an RPG ILE program, with a text
string being populated to a single field in the data base file 1000
characters long. The string is delimited with commas for fields and
double quotes (") for string fields. The file is then accessed
through a CL where the CPYTOIMPF command is run. The issue arises
because a string delimited (") is appearing at the end of the first
character field. This is our regular string delimiter as defined in
the CPYTOIMPF command (listed below).

CPYTOIMPF FROMFILE(QTEMP/HDCSVDLY) TOSTMF(&PATH) MBROPT(*REPLACE) STMFCODPAG(*PCASCII) RCDDLM(*CRLF) DTAFMT(*DLM) STRDLM('"') FLDDLM(',')

<<SNIP>>

Be sure that the TOSTMF() viewed, is indeed the actual target of the request; i.e. the correct output file is being viewed for verifying the data -- possibly a result of relative vs absolute path specification.
Was the data in the QTEMP/HDCSVDLY table verified to *not* have the quote character already[, up to its 1000th character]; is it possible the RPG is incorrectly adding the quote?
What is the CREATE TABLE QTEMP/HDCSVDLY that was used? And given there was no extra quote in the data already, as verified, what is an example of an INSERT INTO QTEMP/HDCSVDLY VALUES( ... ) which exhibits the issue in the output of a test using the given CPYTOIMPF invocation?

I recall in the old export code, IIRC only in the v5r2 path and earlier [verify, if on a newer release, that the data area for the old code path is not in effect], where a /single column/ export had issues. However I thought that was limited to *FIXED versus *DLM being used. Regardless, test if adding another column to the QTEMP/HDCSVDLY table resolves the issue, if still not resolved after the aforementioned.

Regards, Chuck