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



On 20-Jul-2016 06:05 -0500, Rob Berendt wrote:
On 20-Jul-2016 05:50 -0500, Carel wrote:
On 19-Jul-2016 14:13 -0500, John Yeung wrote:
On Tue, Jul 19, 2016 at 11:13 AM, Carel wrote:
If you want column headings, you need a query with a UNION;
the numeric/decimal values in columns have therefore to be
converted to character (using DIGITS).

Not necessarily. Very recently there was a thread discussing the
ADDCOLNAM parameter on modern versions of CPYTOIMPF. It's kind
of underdocumented, but it's there when you press F9 to show all
parameters.

True. But:

- We do not know which OS version the OP is on.

- The ADDCOLNAM parameter will be using the field name (column
name) as defined. With DDS those could be cryptic with 10
characters max.

Adding your own column headings may be more informative.

Wasn't with DDS. It was with a Query output file. I guess that makes
it user controllable. Still have that 10 character limitation though
but it is something to consider.

Just as little is known about the file as with the VRM. The OP suggested only that the file was "created during a customer query". So not necessarily a Query either; i.e. the upper-cased term, typically implying WRKQRY or RUNQRY of Query/400.

In any case, the query [Query or SQL] will carry the long names [i.e. the CQE or SQE query maintains the "Alternative name" aka ALIAS]. Thus the use of ADDCOLNAM(*SYS) or ADDCOLNAM(*SQL) are possibly helpful.

Nevertheless, Carel's suggestion was for use of Column Headings. And whiel a ColHdg may be carried over in a Query/400 Query Definition (QRYDFN), I expect ColHdgs are not [at least are less likely to be] carried by an SQL query [at least not for which the Query/400 feature was not invoked to create a non-SQL object] and thus an output file would await the LABEL ON request(s) -- thus trying to include the ColHdgs in the export might be the least worthwhile, as they may all be NULL, or no better than ADDCOLNAM(*SQL) because IIRC, both the catalogs [and Display File Field Descriptions (DSPFFD)] are designed to return the long-name for lack of ColHdg per an effective COALESCE(colhgd, longColName).

And with regard to the query with UNION to get the column headings and having to cast the numeric data to character string data, e.g. in a VIEW that would be exported, much simpler IMO to generate the CSV string separately and export the TABLE and then append to that generated ColHdg data, the export of the data in the database file as generated by the CPYTOIMPF. The implied query would be doing [much of] the work that the export feature would be doing normally [i.e. converting to character], and then care must be taken to avoid loss of the decimal point and sign which DIGITS() would lose, and if more appropriately using CHAR or VARCHAR then depending on the recipient care might be necessary to avoid including a string delimiter on the numeric data.


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.