The data is EBCDIC on the server. Not sure of the source from where it
comes, so there could be a conversion issue when it reaches our server.

I was thinking about LF with translation, but was hoping for a simple
switch on the data transfer client side. Lacking that, it appears the LF
is the best I can go with.

Thanks!
- Dan

On Thu, Sep 3, 2015 at 4:15 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 03-Sep-2015 12:50 -0600, Dan wrote:

i Access for Windows v7r1, at latest service level SI56695

I transfer data into Excel and occasionally will attempt to transfer
a record that causes a data conversion error (CWBTF0105). Thus far,
it's been caused by a byte in a character field that has a value of
x'00', x'11', or some other value less than x'20'. This is data from
an external source, so I have no control over it.


Is the data being transferred from an EBCDIC or ASCII character column?
Regardless, a column containing such non-printable characters is more
appropriately /binary/ [not /character/] data.

Perhaps when importing the data from the "external source",
correct\convert the _character_ data upon receipt; convert the
non-printable values into code-points that represent characters with
visible glyphs, into a [required] space character, or into the code-point
for the respective substitution (SUB) character for the encoding. The
application could perform the conversion, or perhaps a [native or SQL]
TRIGGER.

<<SNIP>>

Ideas appreciated.


A logical representation of the data could be referenced for transfer,
instead of the physical data, for which conversion of the data occurs upon
transfer of the data; e.g. using a DDS-LF with the TRNTBL keyword could
accomplish that, naming a *CVT Translate Table (TBL) [created from *PROMPT
or from source with: Create Table (CRTTBL)].

--
Regards, Chuck


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].