Re: Transferring Unicode data

Mark,

What's the SQL error you get when trying to create the file?

What version of iAccess?

How does the plugin define the columns?

Usually, what I do is select just the first few rows and transfer those in
while creating the file.

Then I go back and try to transfer the whole thing. 9 times out of 10 it
fails because of garbage in the Excel. You have to track it down and fix
it.

Alternatively, if this is going to be an ongoing process and you can't
ensure the validity of the data, then either build or buy a tool that will
allow you to clean up the data as you load it. If you want to DIY, John's
suggestions of Python or Java POI are the two main options.

Charles


On Thu, Feb 25, 2016 at 9:34 PM, mlazarus <mlazarus@xxxxxxxx> wrote:

Charles,

I'm trying to use the plug in, but it keeps saying that there's a data
type mismatch. I have tried CCSID's of 13488, 1200, 1208 and 404. I even
tried to have the upload transfer create the file and that generates an SQL
syntax error. Any other ideas?

-mark


On 2/25/2016 1:03 PM, Charles Wilt wrote:

I'd transfer the data directly from excel using the data transfer add-in.

Charles

On Thu, Feb 25, 2016 at 10:59 AM, mlazarus<mlazarus@xxxxxxxx> wrote:

What is the "safest" way to do file transfers with Unicode data?
Meaning, to keep the integrity of the data, not from a security
standpoint.

I need to transfer multi-language files between outside sources (to and
from the system), e.g. Excel, or other PC file and the IFS or a native
*FILE. I have tried various methods, but along the way some data gets
garbled. Example:
- In Excel, I saved it as Unicode text.
- Drag and drop from the PC to the IFS via Navigator.
- CPYFRMIMPF to a DB. DDS Definition:

COL1 40G CCSID(13488 20)
COL2 40G CCSID(13488 20)
LONGFIELD 2000G CCSID(13488 1000)

- Reverse the steps to bring back to the PC.

The result is:
COL1 contains the data, but has a leading x'25' in all the records,
except
the first, which had a bunch of x'33' characters, instead of real data.

COL2 seems to be OK.

LONGFIELD gets a bit garbled, but not completely.

COL1 and COL2 only contain numbers and some basic punctuation, like a
'-', so it might be coincidence that the data is OK there.

Since there are several steps happening during the transfer and I can't
display the representative characters on a 5250 style session (those
languages are not loaded on the system), it's tough to debug this.

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--

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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.