by Michael S. Kaplan, published on 2008/05/28 02:06 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/05/27/8556091.aspx
Self-identifying software developer and SQL Server database administrator Julia asked via the Contact link:
Last November you talked about Windows only cultures providing a potential solution for the collation differences between SQL Server and the .NET Runtime. Do you know whether this solution will be used in the upcoming version of SQL?
Fascinating question, Julia!
The blog she is referring to is When yesterday's workaround becomes tomorrow's potential solution... from the end of November of last year.
In it I pointed out how Windows-only CultureInfo objects, where .NET's CultureInfo is synthesized via Win32 NLS API function calls, open a fascinating conceptual door.
Because all SQL Server would have to do is re-expose their own internal collation functions to the CLR, and this would allow some future version of .NET to support "SQL-only CultureInfo objects", for lack of a better term.
And this design would solve the current problem where .NET's collation behavior does not match SQL Server's, even when one is including managed code in one's stored procedures.
Conceptually, this seemed to me like the geek equivalent of what basketball fans might think of as a three-pointer. If you know what I mean....
Alas, as any people playing with the SQL Server 2008 CTPs (including me, as I pointed out in On changing the world, or at least the way people order things in it) can testify, this is really not what is happening in SQL Server 2008, mostly.
The "mostly" refers to an interesting exception -- if one is
then one can actually get comparable results in their managed code running in their stored procedures.
I don't think there was specific intent behind this, though -- it looks more like a bunch of components behaving as they are designed to running into a somewhat fortuitous circumstance.
It would take a bit more overt work, in future versions of both SQL Server and the .NET CLR's Base Class Libraries, to completely "hook up" this solution and allow the results to be not just comparable but truly equivalent....
Now I have no idea if this is planned for the future or not, though I do know that until and unless that happens, in the meantime all of the built-in .NET CultureInfo objects and there CompareInfo objects will be much further away from the new 10.0 collations in SQL Server 2008.
I'll be talking more about this topic another day....
This post sponsored by ག (U+0f42 a.k.a. TIBETAN LETTER GA)
referenced by
2008/09/25 You're not my type if you have no culture