Comments on: SQL Server and conversion of local character

By: miha

miha — Sun, 22 Nov 2009 16:06:45 +0000

[Unfortunately] true with regards to perf… That would not be the case, however, if they would’ve used UTF-8 instead of UTF-16…
Anyhow, the main “issue” still stands. Identically configured databases (with regards to collation), but different behavior.

By: Mladen

Mladen — Sun, 22 Nov 2009 14:46:51 +0000

try this:
CREATE TABLE t1
(
name varchar(10) collate
–Slovenian_CI_AI
SQL_Latin1_General_CP1_CS_AS
)
go
insert into t1 select ‘čćžšđ’ union all select upper(’čćžšđ’)
SELECT * FROM t1
go
drop table t1

you’ll see that the Č is getting downgraded to C when using SQL_Latin1_General_CP1_CS_AS and not when using Slovenian_CI_AI even though the column is varchar.

as for Nvarchar default this may lead to serious perf degradation on very large db’s because you get twice less data read as you could with varchar.

By: miha

miha — Sat, 21 Nov 2009 11:36:42 +0000

Sure. I vote for nvarchar data type to be default.

By: Miha Markič

Miha Markič — Sat, 21 Nov 2009 09:34:54 +0000

I’d expect š to work but wouldn’t expect ž. Anyway, I always use nXXX when working with multilingual or just Slovene language.

By: miha

miha — Sat, 21 Nov 2009 06:23:17 +0000

Mladen, I’m puzzled. Your code works. Your code, without the collation on the column, works. The default database collation is Slovenian_CI_AS.

What is very interesting, at least to me, is that the error (for me, at least) happened only in hosting scenarios, where database collation is the same as the one on my local machine.

By: Mladen

Mladen — Fri, 20 Nov 2009 21:34:57 +0000

btw you can get around that if you set the collation of the column to Slovenian_100_CI_AI
and still have it as varchar.

CREATE TABLE t1 (name varchar(10) collate Slovenian_100_CI_AI)
go
insert into t1 select ‘čćžšđ’ union all select upper(’čćžšđ’)
SELECT * FROM t1
go
drop table t1

the said behaviour happens if you use SQL_* ollations which are not recommended to be used anymore.