Combination of English and Chinese characters in Microsoft SQLServer 2000

Hello,
We have Microsoft SQL Server 2000 with Service Pack 3a installed. In
one of our databases, we have a table REQ with one of the fields
COMMENT being defined as TEXT. Now, when we try to view the COMMENT
field, it shows us only English characters whereas the Chinese
characters are displayed as ?.
Is it possible to store both English and Chinese characters in the same
column of a table? If yes, then how?
Thanks in advance.
New user.
It still does not work. Is there any other alternative?
On Nov 19, 1:48 am, "Dejan Sarka"
<dejan_please_reply_to_newsgroups.sa...@.avtenta.si > wrote:
> --
> Dejan Sarkahttp://www.solidqualitylearning.com/blogs/
|||newsqlserveruser (trupti.pujara@.gmail.com) writes:
> We have Microsoft SQL Server 2000 with Service Pack 3a installed. In
> one of our databases, we have a table REQ with one of the fields
> COMMENT being defined as TEXT. Now, when we try to view the COMMENT
> field, it shows us only English characters whereas the Chinese
> characters are displayed as ?.
> Is it possible to store both English and Chinese characters in the same
> column of a table? If yes, then how?
Yes, it's possible, but with the information you have given, it's difficult
to give exact advice.
First of all, which character set do you use for Chinese? Unicode? Big-5?
If you use Unicode, you should use ntext, if you use Big-5 or any other
non-Unicode character set, you should use text.
Next question is find out where things go wrong. Do something like:
SELECT substring(col, 1, 20), convert(binary(20), substring(col, 1, 20))
If there are question marks in the selected substring which should have
been Chinese characters, what do you see in their place in the binary
string? If you see 3F, the Chinese characters have been stored as ?, and
there is a problem on input. If you see the codes for the Chinese
characters, it's a display problem.
If it is an input problem, it would help to know who the characters enters
the database.
Disclaimer: I have no experience of working with Chinese on my own.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
|||I ran the query as u suggested and the output for the binary string
shows as 3F for the Chinese characters. If that means there is a
problem in input, how do I go ahead from here?
On Nov 21, 9:17 pm, Erland Sommarskog <esq...@.sommarskog.se> wrote:
> newsqlserveruser (trupti.puj...@.gmail.com) writes:
> to give exact advice.
> First of all, which character set do you use for Chinese? Unicode? Big-5?
> If you use Unicode, you should use ntext, if you use Big-5 or any other
> non-Unicode character set, you should use text.
> Next question is find out where things go wrong. Do something like:
> SELECT substring(col, 1, 20), convert(binary(20), substring(col, 1, 20))
> If there are question marks in the selected substring which should have
> been Chinese characters, what do you see in their place in the binary
> string? If you see 3F, the Chinese characters have been stored as ?, and
> there is a problem on input. If you see the codes for the Chinese
> characters, it's a display problem.
> If it is an input problem, it would help to know who the characters enters
> the database.
> Disclaimer: I have no experience of working with Chinese on my own.
> --
> Erland Sommarskog, SQL Server MVP, esq...@.sommarskog.se
> Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
> Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
|||newsqlserveruser (trupti.pujara@.gmail.com) writes:
> I ran the query as u suggested and the output for the binary string
> shows as 3F for the Chinese characters. If that means there is a
> problem in input, how do I go ahead from here?
To start with, please answer a few questions:
1) How does the data enter the database? From a Windows client? From a
web client? Which API do you use?
2) Which character set does the client use for the data?
3) What is the collation of the text column? (You can view this with
sp_help.)
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
|||Thank you very much for all your help. The problem has been solved.
After changing the field from text to ntext in the database, the client
still had some problems. Even though East Asian languages were
supported, the Language for non-Unicode programs was English. When it
was changed to Chinese and the PC was rebooted, everything is all fine
now.
On Nov 26, 1:15 am, Erland Sommarskog <esq...@.sommarskog.se> wrote:
> newsqlserveruser (trupti.puj...@.gmail.com) writes:
> 1) How does the data enter the database? From a Windows client? From a
> web client? Which API do you use?
> 2) Which character set does the client use for the data?
> 3) What is the collation of the text column? (You can view this with
> sp_help.)
> --
> Erland Sommarskog, SQL Server MVP, esq...@.sommarskog.se
> Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
> Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

collection name question

1 of my SQL 2000 servers has few databases that acts as backend for web based
..NET applications, most of them is in English and they have collection name:
SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db which
stores Italian text has collection name: <empty> .. my questions are what it
should be? are there any potential problems we can run into? can you change
it afterwords?
TIA
Hi Rafal,
Databases can not have an empty collation. You can check the collation for
the database in Enterprise Manager by right-clicking the database and
selecting Properties, or by executing
SELECT DATABASEPROPERTYEX('<db name>', 'Collation')
in Query Analyzer.
The only place I can think of where you might see an 'empty' collation, is
when you use the table designer in Enterprise Manager and you look at a
character column that has the default collation for the database.
Jacco Schalkwijk
SQL Server MVP
"Rafal W." <RafalW@.discussions.microsoft.com> wrote in message
news:EA462D24-9ECE-4916-A41D-7CEDF1EE969D@.microsoft.com...
>1 of my SQL 2000 servers has few databases that acts as backend for web
>based
> .NET applications, most of them is in English and they have collection
> name:
> SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db
> which
> stores Italian text has collection name: <empty> .. my questions are what
> it
> should be? are there any potential problems we can run into? can you
> change
> it afterwords?
> TIA
>

collection name question

1 of my SQL 2000 servers has few databases that acts as backend for web base
d
.NET applications, most of them is in English and they have collection name
:
SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db whic
h
stores Italian text has collection name: <empty> .. my questions are what it
should be? are there any potential problems we can run into? can you change
it afterwords?
TIAHi Rafal,
Databases can not have an empty collation. You can check the collation for
the database in Enterprise Manager by right-clicking the database and
selecting Properties, or by executing
SELECT DATABASEPROPERTYEX('<db name>', 'Collation')
in Query Analyzer.
The only place I can think of where you might see an 'empty' collation, is
when you use the table designer in Enterprise Manager and you look at a
character column that has the default collation for the database.
Jacco Schalkwijk
SQL Server MVP
"Rafal W." <RafalW@.discussions.microsoft.com> wrote in message
news:EA462D24-9ECE-4916-A41D-7CEDF1EE969D@.microsoft.com...
>1 of my SQL 2000 servers has few databases that acts as backend for web
>based
> .NET applications, most of them is in English and they have collection
> name:
> SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db
> which
> stores Italian text has collection name: <empty> .. my questions are what
> it
> should be? are there any potential problems we can run into? can you
> change
> it afterwords?
> TIA
>

collection name question

1 of my SQL 2000 servers has few databases that acts as backend for web based
.NET applications, most of them is in English and they have collection name:
SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db which
stores Italian text has collection name: <empty> .. my questions are what it
should be? are there any potential problems we can run into? can you change
it afterwords?
TIAHi Rafal,
Databases can not have an empty collation. You can check the collation for
the database in Enterprise Manager by right-clicking the database and
selecting Properties, or by executing
SELECT DATABASEPROPERTYEX('<db name>', 'Collation')
in Query Analyzer.
The only place I can think of where you might see an 'empty' collation, is
when you use the table designer in Enterprise Manager and you look at a
character column that has the default collation for the database.
--
Jacco Schalkwijk
SQL Server MVP
"Rafal W." <RafalW@.discussions.microsoft.com> wrote in message
news:EA462D24-9ECE-4916-A41D-7CEDF1EE969D@.microsoft.com...
>1 of my SQL 2000 servers has few databases that acts as backend for web
>based
> .NET applications, most of them is in English and they have collection
> name:
> SQL_Latin1_General_CP1_Cl_AS.. I just noticed that recently deployed db
> which
> stores Italian text has collection name: <empty> .. my questions are what
> it
> should be? are there any potential problems we can run into? can you
> change
> it afterwords?
> TIA
>

Collations

Hi,
I'm starting to build a database that will contain English and Welsh
text. Up until now I have just used the default collation settings, and
everything has been fine - but I've only ever needed to use English.
There is also the possibility that, at some point in the future, the
database will have to handle several Arabic and Asian languages.
So, my question is what collation should I used to make the database as
future-proof as possible given the statements above? Does, for example,
the default collation actually support the Welsh alphabet? (Welsh has
four extra characters that I don't think appear in other European
languages - ?, ? and their upper case equivalents - possibly more, but I
don't actually know Welsh!) I notice that there isn't a bog-standard
"UTF-8" option in the collation list...
Lastly, does anyone have any general tips regarding multi-lingual databases?
Cheers,
Dylan Parry
http://electricfreedom.org | http://webpageworkshop.co.uk
The opinions stated above are not necessarily representative of
those of my cats. All opinions expressed are entirely your own.Hi Dylan,
Basically you collation should be the local environment where it is. So if
its in the UK it should be english etc.
With regards to your text, what you need to do is have the appropriate
datatype's for your tables.
For storing text that you would want as not only english, but another
language, instead of using a datatype of say char(10) you would use
nchar(10) this N, ensures that the type is unicode and not ANSI. Text
conversions of char can have mistakes, yet nchar represents the characters
as they should. One important note, using nchar instead of char, will
consume twice as much space as char, so just something to bear in mind.
hth
Barry Andrew
"Dylan Parry" <usenet@.dylanparry.com> wrote in message
news:460d0c87$0$761$bed64819@.news.gradwell.net...
> Hi,
> I'm starting to build a database that will contain English and Welsh
> text. Up until now I have just used the default collation settings, and
> everything has been fine - but I've only ever needed to use English.
> There is also the possibility that, at some point in the future, the
> database will have to handle several Arabic and Asian languages.
> So, my question is what collation should I used to make the database as
> future-proof as possible given the statements above? Does, for example,
> the default collation actually support the Welsh alphabet? (Welsh has
> four extra characters that I don't think appear in other European
> languages - ?, ? and their upper case equivalents - possibly more, but I
> don't actually know Welsh!) I notice that there isn't a bog-standard
> "UTF-8" option in the collation list...
> Lastly, does anyone have any general tips regarding multi-lingual
> databases?
> Cheers,
> --
> Dylan Parry
> http://electricfreedom.org | http://webpageworkshop.co.uk
> The opinions stated above are not necessarily representative of
> those of my cats. All opinions expressed are entirely your own.|||Barry Andrew Hall wrote:
> Hi Dylan,
> Basically you collation should be the local environment where it is.
> So if its in the UK it should be english etc.
Ah okay - so I should simply leave it "as is", right?

> With regards to your text, what you need to do is have the
> appropriate datatype's for your tables.
> For storing text that you would want as not only english, but another
> language, instead of using a datatype of say char(10) you would use
> nchar(10) this N, ensures that the type is unicode and not ANSI.
> Text conversions of char can have mistakes, yet nchar represents the
> characters as they should.
Right, I understand now. So instead of using "text" to store several
paragraphs of writing, I should use "ntext" - but only in places that
could contain Welsh text.

> One important note, using nchar instead of char, will consume twice
> as much space as char, so just something to bear in mind.
In much the same way as saving a text file in UTF-8 instead of
ISO-8859-1 will consume more space. That's not too much of an issue for
me, although I guess it could cause degradation in performance?
Dylan Parry
http://electricfreedom.org | http://webpageworkshop.co.uk
The opinions stated above are not necessarily representative of
those of my cats. All opinions expressed are entirely your own.|||Your right on the performance. But to be fair, if its designed solidly you
shouldnt have a thing to worry about.
Also, as you said, anything you want potentially in another language, have a
datatype of nvarchar(max) thats probably your best bet.
"Dylan Parry" <usenet@.dylanparry.com> wrote in message
news:460d1330$0$757$bed64819@.news.gradwell.net...
> Barry Andrew Hall wrote:
> Ah okay - so I should simply leave it "as is", right?
>
> Right, I understand now. So instead of using "text" to store several
> paragraphs of writing, I should use "ntext" - but only in places that
> could contain Welsh text.
>
> In much the same way as saving a text file in UTF-8 instead of
> ISO-8859-1 will consume more space. That's not too much of an issue for
> me, although I guess it could cause degradation in performance?
> --
> Dylan Parry
> http://electricfreedom.org | http://webpageworkshop.co.uk
> The opinions stated above are not necessarily representative of
> those of my cats. All opinions expressed are entirely your own.

Collations

Hi,
I'm starting to build a database that will contain English and Welsh
text. Up until now I have just used the default collation settings, and
everything has been fine - but I've only ever needed to use English.
There is also the possibility that, at some point in the future, the
database will have to handle several Arabic and Asian languages.
So, my question is what collation should I used to make the database as
future-proof as possible given the statements above? Does, for example,
the default collation actually support the Welsh alphabet? (Welsh has
four extra characters that I don't think appear in other European
languages - ŵ, ŷ and their upper case equivalents - possibly more, but I
don't actually know Welsh!) I notice that there isn't a bog-standard
"UTF-8" option in the collation list...
Lastly, does anyone have any general tips regarding multi-lingual databases?
Cheers,
--
Dylan Parry
http://electricfreedom.org | http://webpageworkshop.co.uk
The opinions stated above are not necessarily representative of
those of my cats. All opinions expressed are entirely your own.Hi Dylan,
Basically you collation should be the local environment where it is. So if
its in the UK it should be english etc.
With regards to your text, what you need to do is have the appropriate
datatype's for your tables.
For storing text that you would want as not only english, but another
language, instead of using a datatype of say char(10) you would use
nchar(10) this N, ensures that the type is unicode and not ANSI. Text
conversions of char can have mistakes, yet nchar represents the characters
as they should. One important note, using nchar instead of char, will
consume twice as much space as char, so just something to bear in mind.
hth
Barry Andrew
"Dylan Parry" <usenet@.dylanparry.com> wrote in message
news:460d0c87$0$761$bed64819@.news.gradwell.net...
> Hi,
> I'm starting to build a database that will contain English and Welsh
> text. Up until now I have just used the default collation settings, and
> everything has been fine - but I've only ever needed to use English.
> There is also the possibility that, at some point in the future, the
> database will have to handle several Arabic and Asian languages.
> So, my question is what collation should I used to make the database as
> future-proof as possible given the statements above? Does, for example,
> the default collation actually support the Welsh alphabet? (Welsh has
> four extra characters that I don't think appear in other European
> languages - ŵ, ŷ and their upper case equivalents - possibly more, but I
> don't actually know Welsh!) I notice that there isn't a bog-standard
> "UTF-8" option in the collation list...
> Lastly, does anyone have any general tips regarding multi-lingual
> databases?
> Cheers,
> --
> Dylan Parry
> http://electricfreedom.org | http://webpageworkshop.co.uk
> The opinions stated above are not necessarily representative of
> those of my cats. All opinions expressed are entirely your own.|||Barry Andrew Hall wrote:
> Hi Dylan,
> Basically you collation should be the local environment where it is.
> So if its in the UK it should be english etc.
Ah okay - so I should simply leave it "as is", right?
> With regards to your text, what you need to do is have the
> appropriate datatype's for your tables.
> For storing text that you would want as not only english, but another
> language, instead of using a datatype of say char(10) you would use
> nchar(10) this N, ensures that the type is unicode and not ANSI.
> Text conversions of char can have mistakes, yet nchar represents the
> characters as they should.
Right, I understand now. So instead of using "text" to store several
paragraphs of writing, I should use "ntext" - but only in places that
could contain Welsh text.
> One important note, using nchar instead of char, will consume twice
> as much space as char, so just something to bear in mind.
In much the same way as saving a text file in UTF-8 instead of
ISO-8859-1 will consume more space. That's not too much of an issue for
me, although I guess it could cause degradation in performance?
--
Dylan Parry
http://electricfreedom.org | http://webpageworkshop.co.uk
The opinions stated above are not necessarily representative of
those of my cats. All opinions expressed are entirely your own.|||Your right on the performance. But to be fair, if its designed solidly you
shouldnt have a thing to worry about.
Also, as you said, anything you want potentially in another language, have a
datatype of nvarchar(max) thats probably your best bet.
"Dylan Parry" <usenet@.dylanparry.com> wrote in message
news:460d1330$0$757$bed64819@.news.gradwell.net...
> Barry Andrew Hall wrote:
>> Hi Dylan,
>> Basically you collation should be the local environment where it is.
>> So if its in the UK it should be english etc.
> Ah okay - so I should simply leave it "as is", right?
>> With regards to your text, what you need to do is have the
>> appropriate datatype's for your tables.
>> For storing text that you would want as not only english, but another
>> language, instead of using a datatype of say char(10) you would use
>> nchar(10) this N, ensures that the type is unicode and not ANSI.
>> Text conversions of char can have mistakes, yet nchar represents the
>> characters as they should.
> Right, I understand now. So instead of using "text" to store several
> paragraphs of writing, I should use "ntext" - but only in places that
> could contain Welsh text.
>> One important note, using nchar instead of char, will consume twice
>> as much space as char, so just something to bear in mind.
> In much the same way as saving a text file in UTF-8 instead of
> ISO-8859-1 will consume more space. That's not too much of an issue for
> me, although I guess it could cause degradation in performance?
> --
> Dylan Parry
> http://electricfreedom.org | http://webpageworkshop.co.uk
> The opinions stated above are not necessarily representative of
> those of my cats. All opinions expressed are entirely your own.

Collation settings for a website in Russian

I am using html, vbscript, asp and sql server.
The website is mainly in Russian but may have some English.
The consensus appears to be that it is best to use utf-8, so I plan to use
html charset utf-8, asp codepage 65001 and ntext, nchar and nvarchar
character
types.
If the above is correct, what collation should I use in SQL Server?
Thanking you in anticipation.
Posted Via webservertalk.com Premium Usenet Newsgroup Services
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
http://www.webservertalk.com
It all depends on what type of data you are storing and is it
case-sensitive/case-insensetive in the DB. Run the following query and
will explain you each collation usage.
SELECT *
FROM ::fn_helpcollations()
-SAI

Collation settings for a website in Russian

I am using html, vbscript, asp and sql server.
The website is mainly in Russian but may have some English.
The consensus appears to be that it is best to use utf-8, so I plan to use
html charset utf-8, asp codepage 65001 and ntext, nchar and nvarchar
character
types.
If the above is correct, what collation should I use in SQL Server?
Thanking you in anticipation.
Posted Via mcse.ms Premium Usenet Newsgroup Services
----
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----
http://www.mcse.msIt all depends on what type of data you are storing and is it
case-sensitive/case-insensetive in the DB. Run the following query and
will explain you each collation usage.
SELECT *
FROM ::fn_helpcollations()
-SAI

Collation settings for a website in Russian

I am using html, vbscript, asp and sql server.
The website is mainly in Russian but may have some English.
The consensus appears to be that it is best to use utf-8, so I plan to use
html charset utf-8, asp codepage 65001 and ntext, nchar and nvarchar
character
types.
If the above is correct, what collation should I use in SQL Server?
Thanking you in anticipation.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----
http://www.usenet.comIt all depends on what type of data you are storing and is it
case-sensitive/case-insensetive in the DB. Run the following query and
will explain you each collation usage.
SELECT *
FROM ::fn_helpcollations()
-SAI

Collation problem

How can I set the database can read english, chinese Traditional and chinese
simplified?
ThanksTo store Chinese characters you will need to use appropriate collation (i.e.
Chinese_PRC_Stroke_CS_AS_KS_WS) for the database/table/column plus setting
the datatype for the column to nchar/nvarchar/ntext.
-oj
"Vincent" <aaa@.aaa.com> wrote in message
news:%235vsUTIGFHA.3732@.tk2msftngp13.phx.gbl...
> How can I set the database can read english, chinese Traditional and
> chinese
> simplified?
> Thanks
>|||Vincent,
1. Use Unicode data types (nvarchar(), nchar(), ntext)
2. Use the N prefix for string constants, as in N'_文'
3. Use Unicode-ready fonts in Query Analyzer and other places you enter
and read data (Arial MS Unicode, for example)
Steve Kass
Drew University
Vincent wrote:

>How can I set the database can read english, chinese Traditional and chines
e
>simplified?
>Thanks
>
>|||Which collation name should be chose when creating database?
Thanks
"Steve Kass" <skass@.drew.edu> wrote in message
news:uQmkZ2JGFHA.524@.TK2MSFTNGP14.phx.gbl...
> Vincent,
> 1. Use Unicode data types (nvarchar(), nchar(), ntext)
> 2. Use the N prefix for string constants, as in N''
> 3. Use Unicode-ready fonts in Query Analyzer and other places you enter
> and read data (Arial MS Unicode, for example)
> Steve Kass
> Drew University
> Vincent wrote:
>
chinese|||it's OK now
Thanks a lot
"Steve Kass" <skass@.drew.edu> wrote in message
news:uQmkZ2JGFHA.524@.TK2MSFTNGP14.phx.gbl...
> Vincent,
> 1. Use Unicode data types (nvarchar(), nchar(), ntext)
> 2. Use the N prefix for string constants, as in N''
> 3. Use Unicode-ready fonts in Query Analyzer and other places you enter
> and read data (Arial MS Unicode, for example)
> Steve Kass
> Drew University
> Vincent wrote:
>
chinese

Collation problem

Personally I would do a Cyrillic_General_CI_AS to Unicode,
then Unicode to the english translastion.
I would make up a new database with all your char, varchar
and text set to nchar, nvarchar and ntext then copy it
over using DTS.
Then you use the data in the new table to copy over to the
english collation.
Warning though with Unicode, it takes double the space, so
the maximum you can have is 4000 characters as opposed to
8000, so check the maximum sizes before you do it.
Peter
"Age is an issue of mind over matter. If you don't mind,
it doesn't matter."
Mark Twain

>--Original Message--
>Hi,
>I have database in russia with collation:
>Cyrillic_General_CI_AS
>Now I would like to transport data to English database
with english
>collation.
>I would like to convert cyrillic text to latin text, that
can be rad from
>english program.
>What is the best way to do that?
>Thank you,
>Simon
>
>.
>Hi, Peter
I don't want to copy cyrilic text into my database - so, I don't need
nvarchar data type.
I would like to convert cyrlic to latin and then insert into varchar type.
So, that is some kind of translation of data.
Do you have any idea?
lp,S
"Peter The Spate" <anonymous@.discussions.microsoft.com> wrote in message
news:5a0c01c523d0$b46eb0d0$a401280a@.phx.gbl...
> Personally I would do a Cyrillic_General_CI_AS to Unicode,
> then Unicode to the english translastion.
> I would make up a new database with all your char, varchar
> and text set to nchar, nvarchar and ntext then copy it
> over using DTS.
> Then you use the data in the new table to copy over to the
> english collation.
> Warning though with Unicode, it takes double the space, so
> the maximum you can have is 4000 characters as opposed to
> 8000, so check the maximum sizes before you do it.
> Peter
> "Age is an issue of mind over matter. If you don't mind,
> it doesn't matter."
> Mark Twain
>
> with english
> can be rad from|||Hello,
The reason I sugested nchar, nvarchar and ntext is that it
is collation independant, basically its designed to what
you want in converting to different collations.
Have a look at 'Using Unicode Data' in BOL.
So the plan was to convert it into Unicode, then convert
than into Latin.
Your numbers should remain the same regardless of which
collation.
Peter
"There is no such thing as public opinion. There is only
published opinion."
Winston Churchill

>--Original Message--
>Hi, Peter
>I don't want to copy cyrilic text into my database - so,
I don't need
>nvarchar data type.
>I would like to convert cyrlic to latin and then insert
into varchar type.
>So, that is some kind of translation of data.
>Do you have any idea?
>lp,S
>"Peter The Spate" <anonymous@.discussions.microsoft.com>
wrote in message
>news:5a0c01c523d0$b46eb0d0$a401280a@.phx.gbl...
Unicode,
varchar
the
so
to
that
>
>.
>|||Hi Peter,
for example.
In russian database I have something like this:
-'
Now I would like to convert it to latin:
4y mozhete vy chytatypo-ukrayins'ky?
I won't have nVarchar type.
I would like to read from russian database and than convert it to latin (or
to unicode first like you suggest) and than insert into english database as
latin text into varchar column (I don't need nVarchar here because now I
have text in latin.)
But which function converts the text from cyrilic to unicode and than to
latin?
Regards,
Simon
"Peter The Spate" <anonymous@.discussions.microsoft.com> wrote in message
news:5a4301c523d8$ea562770$a401280a@.phx.gbl...
> Hello,
> The reason I sugested nchar, nvarchar and ntext is that it
> is collation independant, basically its designed to what
> you want in converting to different collations.
> Have a look at 'Using Unicode Data' in BOL.
> So the plan was to convert it into Unicode, then convert
> than into Latin.
> Your numbers should remain the same regardless of which
> collation.
> Peter
> "There is no such thing as public opinion. There is only
> published opinion."
> Winston Churchill
>
>
> I don't need
> into varchar type.
> wrote in message
> Unicode,
> varchar
> the
> so
> to
> that