Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
Markdown Monster - The Markdown Editor for Windows

Hungarian Characters and DataRow String Field indexes


:P
On this page:

It must be one of those days where weird problems just crop up…

 

Got a note today from a customer that he couldn't place an order on our site. He got hung up on the security code field of the form. He would hit the page and see a binding error displayed on the control.

 

I went out to check this out right away and sure enough I couldn't duplicate it. But he sent a couple of screen shots that clearly showed a problem. On a hunch I noticed his country as part of the email address – Hungarian and set my browser to Hungarian.

 

Sure enough I saw the failure as well. Now I was able to duplicate the problem. I ran into something similar a while back with Turkish language requests. I switch my ASP.NET operating thread into the locale the user is in so that all content automatically displays the locale specific number and date formatting. Which means this particular request is now running in Hungarian.

 

I also use custom databinding on my forms where the controls bind to an underlying data source – in this case a DataRow. The field bound is ccsecurity in the SQL Server database, and I bound to ccSecurity. The databinding code gets down to eventually accessing the DataRow with:

 

DataRow["ccSecurity"];

 

which fails in Hungarian. However that same code works just fine in English and Western locales. Only if I switch the value to all lower case to match the field name it works:

 

DataRow["ccsecurity"];

 

all upper case works to:

 

DataRow["CCSECURITY"];

 

but this mixed case fails:

 

DataRow["ccSECURITY"];

 

while this works:

 

DataRow["cCSECURITY"];

 

Go figure that one out <g>…

 

Previously in the Turkish language reference the problem was the Turkish I and i which are not the same in the Turkish alphabet. So if you didn't use just the right case it didn't translate quite right.

 

Ideally we should be culture neutral strings, but who are we kidding that this will happen everytime a DataRow index is accessed by string? Especially if this value is declaratively assigned through the UI as it is in my databinding controls. The next best option is to use all upper case where the Turkish characters are most similar to the Latin alphabet.

 

That still doesn't explain why some of the odd mixed case scenarios above work and some fail. Even accounting for the character differences it seems the Turkish I should always fail if it's lower case.

 

 

On a side note, in the ASP.NET Thread Switch entry above I used some code in Application_BeginRequest to set the thread context which works well. ASP.NET 2.0 introduces a new globalization option to automatically detect and switch the thread context. You can do this on the page or in web.config globally:

 

<globalization requestEncoding="utf-8" responseEncoding="Utf-8" culture="auto:en-us"/>

 

Unfortunately in my case I still need to override some of the behavior – specifically the Currency symbol. If you switch the thread context, I want to see numbers and dates properly formatted, but the currency used still needs to by $. So I'd back to overriding the currency symbol in the Application_BeginRequest:

 

Thread.CurrentThread.CurrentCulture.NumberFormat.CurrencySymbol = "$";

 

But this doesn't work – when ASP.NET assigns the locale apparently it uses a custom context that is read-only. Bummer…


The Voices of Reason


 

Rick Strahl
October 05, 2006

# DataRows, String Indexes and case sensitivity with Turkish Locale - Rick Strahl


Rick Strahl's Web Log
October 28, 2006

# Detecting and setting the Locale on the Current ASP.Net Web Request - Rick Strahl's Web Log

Here's a useful tip on how to switch the Locale in your Web Applications to provide proper number and date formatting for users from different countries. Detect the Locale and then switch the current request to this Locale to provide a more customized user experience.

Niek Luuring
January 10, 2007

# re: Hungarian Characters and DataRow String Field indexes

Rick,

Just for your information: there are several locales which have letter sequences that correspond to a single 'letter/sound'. These combinations will be used in locale specific comparisons.

For Hungarian (and I believe some other eastern european languages) this means that the combinations like "cs" will be regarded as a single unit, even in case insensitive ccomparisons, so: cs == CS, but cS <> Cs <> cs.

I thought that TH was another one of those combinations.

We had a lot of fun with these 'case sensitive' database table and field names when deploying our software to eastern europe for the first time. And even more fun when we had to include Oracle support next to SQL server because of the auto upper casing feature for dictionary information.

Sam
March 27, 2008

# re: Hungarian Characters and DataRow String Field indexes

this.ConnectionString = ConfigurationManager.ConnectionStrings;
this.ConnectType = ServerTypes.Oracle;

When i run the Hover program with oracle database i got an error:
could not load file or assembly wwDataOracle or one of its dependencies. The system cannot find the file specified.

Rick Strahl
March 27, 2008

# re: Hungarian Characters and DataRow String Field indexes

@Sam - yes the Oracle provider library is not included in the demos. It's part of wwBusiness but since the samples are using SQL I don't provider the 'extra' assemblies for that. wwBusiness is just for the sample - not meant for you to use necessarily in your applications.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024