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



Download and then convert... in two steps? If the data was binary on Source system then transported as such, the hexadecimal string that makes up the city name should be the same at the target as it is on the source; of course before conversion. What is that hex string, and did it in fact remain the same from the Source system to the Target system for the download? If the data changed, that is probably the [first] problem; review of what\how of the download needs to be reviewed to ensure binary transport of that data.

vis str visual character names hex str 870
'Łódź' = LL620000 LO110000 LD010000 LZ110000 = x'BACE84B7'
'[ódŹ' = SM060000 LO110000 LD010000 LZ120000 = x'4ACE84B9'

What is meant in description of the visual appearance, the glyphs, as they appear presented "in SQL"? Is that after the conversion to Unicode and as retrieved from an SQL [Server] database? If DB2 for i SQL, was the binary string inserted unmodified into an EBCDIC character column with CCSID 870? Consider that the interface to display the characters visually may not be setup appropriately, so the best method to verify the data is using its hex representation; if that is correct and the glyphs incorrect, then only the presentation interface is in need of correction.

Regards, Chuck

Derek Nickless wrote:
I'm trying to download some data from BPCS files that contain
Polish characters. I know that they are held in binary format on
the iSeries and I am trying to convert them into unicode to store
in a sql database. I've tried a number of code pages and the best
I've found is 870, but this doesn't give me the complete
translations. An example is the city name of 'Lodz' which - in
Polish - is 'Łódź', but appears as '[ódŹ' in sql.

<<SNIP>>

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.