If you display the row using isql, that _may_ tell you what you need to
know.

There are known issues with multibyte character sets in FB 1.x. When
storing unicode in FB 1.x, I have found that it works better to set the
character set on the column to NONE when creating the table. I tested
by putting data into the tables using jaybird and then displaying it
using ISQL.

If you choose this approach, you will have to do your localized
collation in the java engine, sine character set NONE allows only binary
sort order. Binary order is great for exact searches, but limits the
use of some of the other features of the engine like dictionary order
collations.

FB 2 is not quite ready for production, but it (allegedly) corrects the
unicode and other multibyte character set handling in the database
engine.

Vulcan, which is still way in the future, makes UTF-8 the character set
of choice.

Ensure that the language support for the characters you need to store is
correctly installed on your machine and that the editing widgets that
you are using are aware of the language configurations

On Thu, 2005-08-04 at 18:21 +1000, Helen Borrie wrote:
> At 07:39 AM 4/08/2005 +0000, you wrote:
> >Hi... I have to be able to store 'unusual' macrons, eg in the word
> >'shogun' there is a line above the 'o'. The 'o' with a line above it
> >is unicode character \u014D
> >
> >I've pasted this value into a column manually using IBexpert; while
> >editing the char is correct, and when I exit editing mode and commit,
> >the value looks like a normal 'o'.
> >If I edit it again it looks correct (the one I originally put in), but
> >if I exit IBexpert and restart, it now looks like a normal 'o', even
> >when editing.
> >
> >This could be an IBexpert problem, but I'm not sure if it's been
> >stored correctly.
>
> The latter. After committing, IBExpert is just showing you what has been
> stored in the database or, rather, your environment's interpretation of that.
>
> >In my java application I retrieve the value via JDBC but when it's
> >displayed in an edit box it doesn't show as a normal 'o' /or/ the
> >special macron, but as an 'undisplayable' block character. I know my
> >application can display the special macron ok because I can paste the
> >correct one in the edit box and view it ok. (It normally then gets
> >stored in the db.)
>
> What you are not telling us is what the character sets of the client and
> the destination column are.
>
>
> >So how can I tell if the database is storing it correctly?
>
> Difficult to say, until we know the conditions under which the characters
> are being stored and retrieved and whether you are inspecting the results
> using a viewing interface that actually supports the images for those
> characters.
>
> >Or could both IBexpert and JDBC be corrupting the character to/from
> >the database?
>
> Both IBExpert will be doing whatever the conditions dictate. So provide
> more information about the conditions....
>
> ./heLen