by Michael S. Kaplan, published on 2012/01/31 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/01/31/10261506.aspx
SQL Server's code page, collation, casing, locale, and resource model are all direct attempts to extend the things that Windows provides in ways that make sense for SQL Server.
This sentence bears repeating, I think. Because it seems (in the words of the late, great George Carlin, vaguely important.
SQL Server's code page, collation, casing locale, and resource model are all direct attempts to extend the things that Windows provides in ways that make sense for SQL Server.
Okay, I feel better now.
Now generally speaking I find the model to be supportable -- for example the way they snapshot the casing table in a given collation version rather than relying on the OS table (which could have disastrous compatibility concerns as they cover multiple versions of collations).
To be honest, even in those cases when I don't agree with what they do at all -- like the way they split user locale/UI language/formatting/collation differently. Or the way they combine "redundant" collations that can cause geopolitical discomfort/technical challenges -- I still respect their choices because, after all, the own the choices and the consequences thereof.
There are two problems that I really think they should fix though, in some future version of theirs:
The fact that the Hosted CLR (aka SQLCLR) doesn't use the SQL Server collations of the server they are on, which truly limits the usefulness of managed code in stored procedures, since you can't code against the server's own behavior.
The fact that SQL Server makes its "server collation" setting based on a DEFAULT_SYSTEM_LOCALE analogue instead of a UI language of the LOCALSYSTEM account analogue, which blocks collations that are from "Unicode only" locales -- e.g. Hindi -- from working as sever collations.
There is no good reason for the limitation itself -- what better reason is there to remove it? :-)
More about this setting here....
Maybe it's our fault; we did, after all, call it DEFAULT_SYSTEM_LOCALE.
I guess they just were just extending our naming mistake of yore....