Sounds like you have three problems:
-- 1. How to store and retrieve the "schwa" character in SQL?
For SQL, I'm afraid that you have to use Unicode if you want to store and
retrieve "schwa" because none of the non-Unicode code pages that SQL
supports defines the character. It sounds like you are already aware of
what moving to Unicode will entail (using nchar/nvarchar for columns and
variables, prefixing Unicode string literals with N).

-- 2. What regional settings/code page to use for the client Windows
machines?
To the best of my knowledge the same is true in Windows. For example, if
you set the default locale for a Windows machine to Azeri (Latin), the
client's Windows code page becomes 1254. This code page does not define
the schwa character (if it did it would solve the problem in SQL as well
since SQL supports this code page). In other words, a Windows app should
handle text as Unicode if it needs to work with strings containing this
character.

-- 3. The lack of Unicode controls (text boxes, etc) in VB prior to VB.NET.
I haven't read it personally, but my understanding is that the book
"Internationalization with Visual Basic" by Michael Kaplan discusses the
problem of the lack of Unicode controls in VB, and suggests some
alternatives. There are third-party controls, and I think a few of the
included native VB controls (rich text?) may support Unicode text, as well.
All strings in VB are already natively Unicode; the problem is in finding
a control that can display a Unicode string without first converting it to
the client machine's non-Unicode code page. Moving to VB.NET is another
option, as I'm sure you're aware.

I wish I knew a better answer for you.

Bart
------------
Please reply to the newsgroup only - thanks.

This posting is provided "AS IS" with no warranties, and confers no rights.



--------------------
Content-Class: urn:content-classes:message
From: "ata" <atag@banksoft.com.tr>
Sender: "ata" <atag@banksoft.com.tr>
References: <1561e01c3858a$449b10e0$a601280a@phx.gbl>
<13V2a3rhDHA.2624@cpmsftngxa06.phx.gbl>
Subject: RE: COLLATION for the reverse e character (nchar(399))
Date: Tue, 30 Sep 2003 01:28:10 -0700
Lines: 102
Message-ID: <181d01c3872c$c8150f40$a101280a@phx.gbl>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Thread-Index: AcOHLMgV2qp5FBlOTy2mHLKhczyzmA==
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Newsgroups: microsoft.public.sqlserver.programming
Path: cpmsftngxa06.phx.gbl
Xref: cpmsftngxa06.phx.gbl microsoft.public.sqlserver.programming:392698
NNTP-Posting-Host: TK2MSFTNGXA09 10.40.1.161
X-Tomcat-NG: microsoft.public.sqlserver.programming

Hi Bart,

I'm pleased that you're interested in my problem.

My problem is as follows:

We have a large database (SQL 2000) that have about 1000
tables and 1000 stored procedures.

All of our current customers use non-Unicode characters
but we're about to have a new customer from Azerbaijan and
the Azerbaijani character "reverse e" (which is nchar
(399)) is not a non-Unicode character as far as I know. I
couldn't find it in the lists in the following links

http://www.microsoft.com/globaldev/reference/cphome.mspx
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDO
WS/

All of the string columns in our database are defined as
char/varchar and all of the string variables in our stored
procedures are also defined as char/varchar.

We have 2 problems:

1. We don't want to change all our columns and variables
from char/varchar to nchar/nvarchar and we don't want to
place an "N" in the insert and update scripts. Instead we
want to find a collation that contains the "reverse e"
character. Also we don't know what should clients' ANSI
code page be.

2. A very big part of our programs are written in Visual
Basic 5.0. We couldn't be able to use the "reverse e"
character in VB 5. (For example we couldn't write the
character on the caption of a form)


I'll be pleased if you help us.

Best regards,
Ata Giray

[quoted text, click to view]