Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 675
  • Last Modified:

How can I read and display unicode Non Latin 1 characters in Lotus Notes from ISeries table using ODBC

I have an Iseries which has a unicode capable field. I have inserted Japanese (and other) non-Latin1 characters into this table.

Using the client access odbc driver I can read these characters successfully into MS Excel.
Using the ISeries access RunSQLstatements ,  I can see these characters when I change the font to unicode.

When I use my lotus notes SQL retreival tools the non-latin1 characters appear as a ? and will not display.

I have set the "Enable Unicode" in preferences to On.

Using ODBC traces it appears that the lotus notes is sending a message to the ODBC driver that it is narrow (??) which indicates non-unicode but this is not correct.

Is Anyone with experience of using lotus notes with ISeries Access ODBC or using Lotus Notes in an ISeries world with unicode able to offer any advice?
0
Cedarsrus
Asked:
Cedarsrus
2 Solutions
 
theo kouwenhovenCommented:
Hi  Cedarsrus,

As far as I know is Japanees a DBCS type character, so you have to use a DBCS at the iSeries side.
See for more in formation the IBM page about "Working with DBCS data"

Regards,
Murph
0
 
CedarsrusAuthor Commented:
Hi Murph ,
The current version of our database is double byte. The newer version that we are having difficulty with moves a number of the key tables to Unicode.
We want to store Japanese, Russian, etc. in these unicode fields.

We've done some more testing and we think it's to do with the Lotus Notes client. The Japanese client can read the unicode data , but the UK Notes client can't.


Andrew
0
 
Sjef BosmanGroupware ConsultantCommented:
0
 
CedarsrusAuthor Commented:
OK - Now we know what the real problem is - Lotus Notes LSX ODBC connector was written for ODBC 2.x and tells the odbc driver what the active code page is to determine whether to use Narrow or wide in its interpretation of the commands and results.

So a Japanese based client sends and receives "wide" but a UK based PC sends a "narrow" and expects "narrow" but can't cope when the returned results are in unicode.

Any suggestions as to how we can work around this ?
0
 
daveslaterCommented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now