Subject RE: [IBDI] Character sets - for the IBDH database
Author David Schnepper
I'm here Helen!

There's two ways to approach this -- let's assume your "key" to identify a
piece of text is Chapter.

create table book_text (
chapter_id integer not null primary key,
english character(30),
french character(50) character set latin1,
japanese character(50) character set sjis, ... )

Note: Languages added / dropped by changing columns. Application code to
access table may need change
each time a language is added / dropped. Note that column widths must vary
to allow for growth in
text for a translation.


create table book_text (
chapter_id integer not null,
language_id integer not null,
text character (50) character set unicode_fss, /*
Alternate 2b: character set none */
primary key (chapter_id, language_id));

(With appropriate tables to track language_id & chapter_id & FK references)

InterBase will automatically transliterate from your application character
set to the storage character set.
If you use character set none, InterBase simply stores & fetches what you
give it - it does not try to change
byte values between different applications. eg: you have to manage text

I like the 2nd approach better. That's how the translation database for
InterBase messages & error text is
set up. (Didn't know there was a database of InterBase translations??? Yet
another project that was setup
in engineering and never was funded for hiring translators. When I left we
had about 75% of a Japanese
translation & 50% each of French & German in the database - Many messages
from the 3.x & 4.x timeframe, and
no new 5.x or 6.x messages having any translations.).


-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Wednesday, March 29, 2000 4:00 AM
Subject: [IBDI] Character sets - for the IBDH database

From: Helen Borrie <helebor@...>

Help All!

I'm storing all of the stuff for the IBDH in an SQL Server database....

JUST KIDDING! an IB database. All was sweet until it hit me like a rock that I
need to store text of different character sets in the one database, nay,
within the same tables. The database is structured on the OpenDoc XML tree
- at the top level is the SET (name BookSET) beneath which is BOOK - one
row for each language.

We go down levels, storing DIVISION, PART, CHAPTER and several different
kinds of components, with several language-specific text columns along the

Is there a magic wand solution for this, other than storing the
language-specific content in lookup tables in separate databases? I hope

(Boy, this is a challenge!)

Dave Schnepper, are you out there?

"Ask not what your free, open-source database can do for you,
but what you can do for your free, open-source database."

Get a NextCard Visa, in 30 seconds! Get rates
as low as 2.9% Intro or 9.9% Fixed APR and no hidden fees.
Learn more at:

Community email addresses:
Post message:
List owner:

Shortcut URL to this page: