From owner-ccnet-l@UGA.CC.UGA.EDU Wed Aug  6 05:24:49 1997
Received: from listmail.cc.uga.edu (listmail.cc.uga.edu [128.192.232.10]) by ccic.fas.harvard.edu (8.6.11/8.6.11) with ESMTP id FAA09324 for <yjj@IFCSS.ORG>; Wed, 6 Aug 1997 05:24:48 -0400
Message-Id: <199708060924.FAA09324@ccic.fas.harvard.edu>
Received: from uga.cc.uga.edu by listmail.cc.uga.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.D656FAA0@listmail.cc.uga.edu>; Wed, 6 Aug 1997 5:16:04 -0400
Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2c/1.8c) with BSMTP id 1479; Wed, 6 Aug 1997 05:15:21 -0400
Date:         Wed, 6 Aug 1997 17:15:31 +0800
Reply-To: Jacob Morrison <Jacob.Morrison@CDC.COM>
Sender: Chinese Computing Network <CCNET-L@UGA.CC.UGA.EDU>
From: Jacob Morrison <Jacob.Morrison@CDC.COM>
Subject:      Re: Multilingual Databases Review
Comments: To: Richard Altwarg <raltwarg@TAPPI.ORG>
To: CCNET-L@UGA.CC.UGA.EDU
In-Reply-To:  <33e0ff5a4264002@cdshub.cdc.com>
Status: R

Richard,

I would love to hear what you come up with.
I will throw in what little I know.

Most popular databases handle various character sets, but only
one at a time.

For multilingual computing, there is really only Unicode
(see http://www.unicode.org/). If you can store Unicode
in your server, then you can handle data in almost any
language simultaneously. This simplifies the design
considerably.

If the database supports Unicode properly,
the data should be transparently translated between the
character set for the database and the character set for the client.
If you are handling your own character set conversion,
Unicode UTF-8 encoding should work with almost any database.
Performance won't be so great, though, compared to UCS2.

Suport for UCS2 is supposed to be in Oracle 7.3,
but no-one in Oracle seems to know what's going on if
you ask how to use it.

One database that is not on your list is ADABAS D from
Software AG. I saw a demo of this at the Unicode converence
in HK a year or so ago. It uses UCS2 internally, allowing very
fast performance. It can do amazing things like join tables
in different character sets on the fly, presenting the
data to the user in the client character set.

SAP can handle Asian characters, but only one character set
per database last time I checked. They may support Unicode now.

The folks at Sybase are active in multilingual computing, but
I haven't seen much come out that's visible.

Excell in Office 97 is supposed to be Unicode now. Certainly
Word is. This means that the same file can be used with any
language version.

Hope this helps.

Regards,
Jake

On Thu, 31 Jul 1997, Richard Altwarg wrote:

> I'm preparing  a survey of available multilingual databases, focusing on
> issues, strengths and weaknesses of what may be out there.  Can
> anyone help?
>
> 1. What is available?  Have you used it?  Or did you build it?  Please give
> me your comments on what is good about it, what is not?  Comments on
> personal experience with localized versions of these and other
> databases:
>
> BAAN
> SAP
> Oracle
> Sybase
> Peoplesoft
> Powerbuilder
> Tables from other word processing and spreadsheet applications
>
> 2.  Does anyone know of any published material on this subject?
>
> 3.  Does anyone know of the methodologies/approaches used by
> organizations using multilingual databases?  Are these structured or ad
> hoc?  Please describe.
>
> If you will send private email requesting same, I would be happy to share
> my findings with any interested parties.
>
> Richard Altwarg
> International Development Coordinator
> TAPPI
> Tel: 770-209-7388
> Fax: 770-209-7315
> raltwarg@tappi.org
>

