Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
MichaelG
Starting Member
11 Posts |
 Posted - 2003-01-27 : 06:10:31
|
| I'm sure this is a common question but I've searched the archives and haven't found anything that quite answers my questions.I'm trying to decide whether I should use char or nchar.My app will be marketed eventually in most western countries but the database would probably need redesigning anyway before being sold in non-western countries.Questions:1. I want the database to stay the same for european countries. What code page issues do I get involved in if I use char?2. Is it correct to assume that SQL Server 2000 handles all data internally as unicode? That is, if I use char is there an implicit conversion to unicode when making queries with ADO of web services and therefore some performance penalty?3. The advantage of using char is more records on a page and therefore better I/O plus some space saving but is it worth it? What would be best practice for a databse storing european languages?Thanks in advance for any advice.Michael |
|
|
KnooKie
Aged Yak Warrior
623 Posts |
Posted - 2003-01-27 : 08:04:53
|
Doesn't exactly answer your questions but.......quote:
Is it correct to assume that SQL Server 2000 handles all data internally as unicode?
YesWe store english and Japanese in our database we have separate name fields for the Japanese. ie with have a fs_PlcName field that is a varchar (why use char at all?) of 150 and in the same table a jfs_PlcName that is a nvarchar of 150 for holding the Japanese names. We can then translate as necessary (or at least people in Japan can)If you don't need to query the Japanese then don't include it in your queries.===========Paul |
 |
|
|
ValterBorges
Master Smack Fu Yak Hacker
1429 Posts |
Posted - 2003-01-27 : 08:07:45
|
quote:
In Microsoft SQL Server, these data types support Unicode data: ncharnvarcharntext Note The n prefix for these data types comes from the SQL-92 standard for National (Unicode) data types.Use of nchar, nvarchar, and ntext is the same as char, varchar, and text, respectively, except that: Unicode supports a wider range of characters.More space is needed to store Unicode characters.The maximum size of nchar and nvarchar columns is 4,000 characters, not 8,000 characters like char and varchar.Unicode constants are specified with a leading N: N'A Unicode string'.All Unicode data uses the same Unicode code page. Collations do not control the code page used for Unicode columns, only attributes such as comparison rules and case sensitivity.
I would go with nvarchar |
|
|
|
|
|
|
|
|
Advice needed on unicode