by Michael S. Kaplan, published on 2006/08/21 06:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/08/21/707790.aspx
The other day, developer Jamie Laflen had a question which VSTS International Program Manager Aldo Donetti forwarded on to me:
I have a test that enumerates all collations in SqlServer and verifies that the string generator can, well, generate strings for each of them.
I hit a weird case for collation:
Georgian_Modern_Sort_BIN
When I run the following:
declare @collation as varchar(60)
select @collation = 'Georgian_Modern_Sort_BIN'
SELECT COLLATIONPROPERTY( @collation, 'LCID')
It returns 66615 for the LCID.
If I then call CultureInfo.GetCulture(66615) it returns a culture "ka-GE." If I then call CultureInfo.GetCulture( "ka-GE" ) it returns a CultureInfo with the LCID == 1079
This is pretty weird.
I did find that the TextInfo object for both CultureInfo instances has its LCID property equal to 1079 (i.e. culture.TextInfo.LCID). For the time being, I changed the code to use the property TextInfo.LCID, but it would be good to understand what is going on here.
Does this make sense? Any ideas?
Jamie
Aldo agreed, saying:
Weird, but I suspect Michael will have an explanation for it. 66615 was already mentioned as the LCID for Georgian in his article on SQL2k Intl. features (now offline but can be downloaded here) so it’s nothing new, but in this page it’s not listed.
I’d agree with your action of using the LCID from the CultureInfo object but I’m very curious to know what 66615 is …
Once again, the SQL Server/DevDiv preference for decimal LCIDs affects developer productivity! :-)
If you look at the hexadecimal numbers, 1079 and 66615 become 0x0437 and 0x10437, the Traditional and Modern Georgian sorts that I have discussed previously....
In .NET 2.0, you can try using CultureInfo.CompareInfo.LCID and CultureInfo.CompareInfo.Name to get back the 0x10437 and ka-GE_modern that you would want here if getting back the right identifier was important. Although CultureInfo.LCID will also return 0x10437, CultureInfo.Name has to return ka-GE for backward compatibility with prior versions of the .NET Framework (and believe me when I tell you this unusual compromise that came out of the argument of LCID/name consistency vs. cross-version consistency was hotly debated at the time!).
The fact that all of this came up in a Unicode only locale (Georgian) in a unit test involving a SQL Server _BIN (binary) sort which means that there is no actual sorting or code page difference of consequence in this sort and that all results will be identical to the Latin1_General_BIN results is of course a separate a point that is interesting to me for the same reason that people discussing the difference between German, Dutch, and English sorting on Windows is.
Ah, the irony of discussing a difference that makes no difference. :-)
On an unrelated note, Aldo has a point here, which I will take to its logical conclusion. The fact that this is the sort of question that I know the answer to is something that I think makes me weird, too!
This post brought to you by ჴ (U+10f4, a.k.a. GEORGIAN LETTER HAR)
# win.sight on 21 Aug 2006 7:51 AM:
# Michael S. Kaplan on 21 Aug 2006 8:02 AM:
# Aldo Donetti on 21 Aug 2006 12:39 PM:
# Dean Harding on 21 Aug 2006 7:57 PM:
# Maurits [MSFT] on 21 Aug 2006 9:42 PM:
# Michael S. Kaplan on 21 Aug 2006 10:57 PM:
referenced by