Nu am lucrat la site-uri cu diferite culturi dar daca as face ar trebui sa stiu pe ce cultura ma aflu si mai este un aspect... de unde stie el(sql server) daca sa tina cont de CASE SENSITIVE sau de CASE INSENSITIVE? (sunt domenii unde trebuie sa se tina cont si domenii unde nu trebuie sa se tine cont ... asta ar trebui stabilit inca de la inceput)
Spre exemplu: caut "katalyn" pe sqlserver.ro .... ar fi frumos ca in cazul in care caut "KATALYN" sa primesc acelasi rezultat dar daca scriu un cod asa cum sunt acele imagini care au rolul de a impiedica programele de tip robot sa publice spam-uri pe diferite blog-uri, sa se tina cont de litera mare/mica.
Conform
http://www.databasejournal.com/features/mssql/article.php/3302341/SQL-Server-and-Collation.htm rezulta ca collation nu are de-a face cu setul de caractere de care va dispune un camp, are de-a face cu reguli de comparare, case sensitive / insensitive etc.
Asa ca idee ... daca ai un camp in care retii: ﺽﻕﻘﺶ; ệỞẺỶ; hX^ ... vei putea folosi nvarchar fara griji pentru ca ele sunt caractere UNICODE. Problema ar fi aceea ce pentru a retine un caracter unicode este nevoie de spatiu de stocare dublu fata de varchar adica 1 byte pentru varchar si 2 bytes pentru nvarchar.
insert into tbl (a,b)
values (N'ﺽﻕﻘﺶ','ﺽﻕﻘﺶ'),(N'ệỞẺỶ','ệỞẺỶ'),(N'hX^','hX^')
SELECT [ a ], [ b ] FROM [dbo].[tbl]
SELECT datalength([ a ]),datalength([ b ]) FROM [dbo].[tbl]
SELECT [ a ], [ b ] FROM [dbo].[tbl] where [ a ] = N'ﺽﻕﻘﺶ'
In exemplul meu de mai sus vei observa ca pe coloana [ b ] apar mai multe semne de intrebare ... asta pentru ca am facut insert cu caractere care sunt non-Unicode. Comparatia de la ultimul select functioneaza corect desi nu am facut nicio jonglerie cu collation...
Cătălin D.