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



Hello Chuck...

I have verified that the output stream file is correct and does not
contain excess delimiters. During testing I have eliminated previous
versions of the stream file to ensure that it is always built anew. I
have also ensured that the work file from which the data is retrieved with
the CPYTOIMPF command is always cleared prior to running the build
command, so we are not dealing with old data.


Here is an actual subset of the delimited data from the file, built using
the procedure. The very first field that would be generated from the
record should contain the value of 1 when it is opened in Excel. Instead,
it contains a value of 1". All the other fields are displayed properly
and have no excess characters in their respective excel spreadsheet
columns.

"1","1019","1"," "," 02/26/2009","8722410 "," 32.77","
.00","128031 ","Debit ","7030"," "

The output was generated using an RPG ILE program with a standard write
command (as opposed to an SQL insert command). I also have tried running
this where a second field was placed into the HDCSVDLY file, but the
results were same.

Have a good day.


Blake Moorcroft
Developer - Corporate
Russell A. Farrow Limited
1980 Ambassador Drive, PO Box 333, Windsor, Ontario N9C 3R4
Bus: 519-966-3003 ext. 566, Fax: 519-966-9870
blake.moorcroft@xxxxxxxxxx




CRPence <CRPbottle@xxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
03/02/2009 01:55 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
midrange-l@xxxxxxxxxxxx
cc

Subject
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

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.