Re: CPYTOIMPF - extra delimiter issue

[CRPence <CRPbottle@xxxxxxxxx>]

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