{KomentoLock}I so much agree with all the other answers.

Make sure your database handles Unicode efficiently (both store text as NCHAR/NVARCHAR and make sure your DB connection is set up for Unicode).

Be aware that some European languages use non-Latin characters. Examples: Greek (EU) and Russian (non-EU).

Final word of caution writing EU-wide apps: Postal address layouts, phone number formats, text sorting, numeric separators, etc. may differ by country. Hungary: space is grouping char so "123 45,78" is a valid number! Danish: "A" sorts before "B" but "AA" sorts after "Z".

Being European has its charms. HTH /Michael

PB 10 and higher will work as long as you use Unicode on the database side, NCHAR/NVARCHAR columns for example.

I have a PB 10.5 SQL Anywhere app being used with Hebrew. Works great since I updated the columns to be NCHAR/NVARCHAR.

Hi Andrew;

  Since newer PB releases are Unicode, capturing any extended characters in an MS-Windows PB App is not normally the problem. The issue typically then resides on the DBMS side where the following Unicode data type changes need to occur ...

Char   => NChar

VarChar => NVarChar

  The key will be to check with your DBMS folks and see what your particular DBMS needs in order to properly support the "Extended"  Unicode character set.

HTH

Regards ... Chris

You need to make sure your database has the proper Unicode support and that you are using the appropriate collation.  The actual display and/or the ability to enter these characters via the keyboard depends upon the regional settings you have within Windows.  PowerBuilder has supported Unicode since version 9 or 10.  You may wish to consult the help for more information.

I think it mostly depends what character set / collation your Database is using. Powerbuilder should not need any adaption, correct me if I'm wrong.

Recommended for the Database would be UTF8 (or maybe even something like "...Latin..." would be enough for the characters you want to store).