EXPORT DELIMITER "µ" in UTF-8 R-Code

I have a huge problem exporting data.
I use OpenEdge 10.2B07 !!

You can reproduce this issue with following source code:

MESSAGE "~265"
VIEW-AS ALERT-BOX INFO BUTTONS OK.

OUTPUT TO VALUE("C:\Temp\Test.asc").
EXPORT DELIMITER "~265" "string1" "string2".
OUTPUT CLOSE.

MESSAGE "doesn't appear"
VIEW-AS ALERT-BOX INFO BUTTONS OK.


/* doesn't work either */
/*MESSAGE "MESSAGE "µ"
VIEW-AS ALERT-BOX INFO BUTTONS OK.

OUTPUT TO VALUE("C:\Temp\Test.asc").

EXPORT DELIMITER "µ" "string1" "string2".

OUTPUT CLOSE.

MESSAGE "doesn't appear"
VIEW-AS ALERT-BOX INFO BUTTONS OK.
*/

It is very important that you compile this code with uft-8, so you have an utf-8 r-code.
It will work when you compile this source with ISO5559-1 or ISO8859-2.

Than start an ISO8859-1 or ISO8859-2 session an run this r-code.
Nothing is exportet and the program aborts with no error message.

In my situation an other delimiter is not possible, because a third party software needs it.

Also an import of a file with this delimiter does not work either with an utf-8 r-code using IMPORT DELIMITER ... .

Regards
 

moveIT

New Member
afaik you can't use CHR(x) or a variable as an export delimiter
Edit: also with "µ" its the same problem
 

Cringer

ProgressTalk.com Moderator
Staff member
Apologies you are right - for some reason I though chr(x) was fine for an export. Evidently not.
 

moveIT

New Member
with the delimiter "~181" the file appears as "string1""string2" without any delimiter
also with ~ you have to use the octal value and the octal value of 181 is 265
 

RealHeavyDude

Well-Known Member
Welcome to the world of internationalization:

You are having a code-page issue. The code-pages iso8859-1 and iso8859-2 are only compatible one way with UTF-8. That means that you can only convert data that is encoded with iso8859-1 or iso8859-2 to UTF-8 and back to iso8859-1 or iso8859-2 when it does not contain any character that are not supported by these code pages. Anyway chances are very likely that you will lose or corrupt data if you don't run the client session with UTF-8 ( see -cpstream and -cpinternal ). Furthermore you might want to have a look in to -cprcodein to convert hard coded text from the r-code text segment in a different code-page as the one the file was compiled with.

While all this will you give you flexibility to some extent you need to be aware that a loss-free conversion is only possible when both, the source code-page and the target code-page, share the same character set. That means that each character is present in both code-pages but encoded differently ( an example for that would be iso8869-1 and ibm850 which are convertable ).

As far as I have seen your special character is neither supported with iso8859-1 nor iso8859-2 and therefore can't be dealt with when running with these code-pages. You would need to fiddle with the conversion map and build you own into convmap.cp ( which is located in the prolang folder of your OpenEdge installation ) in order to use it. Other than that you need to run your client with UTF-8. Full Stop.

Heavy Regards, RealHeavyDude.
 

moveIT

New Member
Welcome to the world of internationalization:

You are having a code-page issue. The code-pages iso8859-1 and iso8859-2 are only compatible one way with UTF-8. That means that you can only convert data that is encoded with iso8859-1 or iso8859-2 to UTF-8 and back to iso8859-1 or iso8859-2 when it does not contain any character that are not supported by these code pages. Anyway chances are very likely that you will lose or corrupt data if you don't run the client session with UTF-8 ( see -cpstream and -cpinternal ). Furthermore you might want to have a look in to -cprcodein to convert hard coded text from the r-code text segment in a different code-page as the one the file was compiled with.

While all this will you give you flexibility to some extent you need to be aware that a loss-free conversion is only possible when both, the source code-page and the target code-page, share the same character set. That means that each character is present in both code-pages but encoded differently ( an example for that would be iso8869-1 and ibm850 which are convertable ).

As far as I have seen your special character is neither supported with iso8859-1 nor iso8859-2 and therefore can't be dealt with when running with these code-pages. You would need to fiddle with the conversion map and build you own into convmap.cp ( which is located in the prolang folder of your OpenEdge installation ) in order to use it. Other than that you need to run your client with UTF-8. Full Stop.

Heavy Regards, RealHeavyDude.
The problem is not that the delimiter is the wrong char, the problem is that when you use "~265" (or CHR(181)) as delimiter, progress exports nothing and doesn't raise an error message...and "~265" should be in every codepage (ISO8859-1 & ISO8859-2)
 

Cringer

ProgressTalk.com Moderator
Staff member
What happens if you do a PUT UNFORMATTED lv-item1 CHR(181) lv-item2... ? It's more long-winded than an export, but might help?
 

RealHeavyDude

Well-Known Member
Then I would suspect that the EXPORT statement does not support extended ASCII characters like yours as delimiter.

Heavy Regards, RealHeavyDude.
 

RealHeavyDude

Well-Known Member
Just did a quick test and this works for me (OE10.1c/WinXP/iso8859-1)
Code:
FIND FIRST someTable.
OUTPUT TO VALUE ( "D:\Data\RAD\Shared\Temp\test.txt" ).
EXPORT DELIMITER "~265" someTable.
OUTPUT CLOSE.
When viewing the result with notepad ...

Heavy Regards, RealHeavyDude.
 

moveIT

New Member
@RealHeavyDude: This works for me too, but when you compile this code as utf-8 and start it with a ISO8859-2 client, it doesn't work anymore..it just stops at the export statement...

@Cringer: This works, but only as a workaround and i still don't understand why it won't work with export delimiter (in UTF-8)http://www.progresstalk.com/member.php?13714-Cringer
 

Cringer

ProgressTalk.com Moderator
Staff member
If the PUT works, but the EXPORT doesn't it may be time to log a support request with Progress. Make sure you attach your working and non-working examples.
 

RealHeavyDude

Well-Known Member
Did you try starting your iso8859-2 client with -cprcodein UTF-8?

I have no installation that contains iso8859-2 at my disposal therefore I can't test it.

Heavy Regards, RealHeavyDude.
 

moveIT

New Member
Did you try starting your iso8859-2 client with -cprcodein UTF-8?

I have no installation that contains iso8859-2 at my disposal therefore I can't test it.

Heavy Regards, RealHeavyDude.
yes i tried it with -cprcodein ISO8859-2 and -cprcodein UTF-8 it doesn't work with either of those

@Cringer I already sent progress this example yesterday but i haven't got any answer yet
 
Top