codepage export data to sql - problem french characters

Posted by Jac01 on 19-Mar-2013 16:59

Hi,

In a  Progress   the codepage used is ibm8858-1. On a unix  machine.

We dumped the data as follows :

export stream strA to /u/dirr/ppd/tesk.txt convert target "1252".

for each tab1 no-lock :

put strA tab1.field1 ";"

tab1.field2  skip.

end.

In vi  the file tesk.txt contains for the french characters \212 etc....

The french words après is showed as   Apr\212s .

Normally we ftp that file to a PC and then via a dtsx it is loaded in sql.

But in sql the french characters are also not in the correct format.

Does somebody knows how we have to export the data.

To load the data in sql the codepage 1252 is used.

Tkx, Jac

All Replies

Posted by Jens Dahlin on 20-Mar-2013 03:06

Are you 100% sure the field doesn't contain "Apr\212s"? I'm also unsure if there is a ibm8858-1 codepage, I'm guessing you might be mixing it up with iso8859-1 (Scandinavian letters).

Whenever I encounter codepage problems the characters are garbled, not converted to something that looks like a ascii code.

You can always try (assuming its really iso8859-1)

convert source "iso8859-1" target "1252".

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/getip.p.zip:550:0]

Posted by Jac01 on 20-Mar-2013 04:54

Hi,

You are right i missed it is iso8859-1. :

Database    =  ISO8859-1  
Collation   =  BASIC    
-cpinternal =  ISO8859-1  
-cpstream   =  ISO8859-1  
-cpcoll     =  Basic

These are the settings.

I already tried a put stream stra codepage-convert(Table1.field1,"1252","iso8859-1") skip.

But no luck in vi we see still something like this

dans un souci de plus grande c\351l\351rit\351.;Nous proc\351dons aux

Tkx,

Nic

Posted by Jens Dahlin on 20-Mar-2013 05:24

Try something like this:

FIND FIRST Table1 NO-LOCK WHERE field1 BEGINS "dans un souci" NO-ERROR.

DISPLAY Table1.Field1 MATCHES "*c\351l\351rit\351*".

Or modify there where clause so you get the record with the mentioned data in.

If it says "YES" then your record actually contains c\351l\351rit\35 etc and not the special characters, é á è à etc.

This thread is closed