DataRows, String Indexes and case sensitivity with Turkish Locale
I’ve been tracking a really funky bug in my West Wind Web Store application that seems to crop up only very infrequently in my error logs. Basically the problem is that for some odd reason a field in a DataRow that indeed exists is not being found. In that previous post I mentioned that I had instituted some additional logging features – specifically making sure that I would also log the locale of the user accessing the application.
Well, 3 bug reports later I noticed that all errors occurred with a Turkish (tr) browser. So I changed my browser’s default language to Turkish and sure enough I could see the error occur. The code that causes the error is here:
public String Itemimage
{
get
{
if (this.DataRow == null)
return this._Itemimage;
if (this.UseColumns)
return (String) this.DataRow[this.ItemimageColumn];
else
return (String) this.DataRow["Itemimage"];
}
set
{
if (DataRow != null)
this.DataRow["Itemimage"] = value;
this._Itemimage = value;
}
}
Seems harmless enough and it works 99% of the time. But when I run with Turkish browser language simulation check out what I get in the debugger here:

The code fails when the fieldname is in mixed case. If I change the field to lowercase only it works fine!!! If I run the same code with most other language impersonations – no problemo. Only in Turkish (so far as I can tell).
Now I should mention that my Web app changes locale on each request to match the user’s locale so that numeric and date values display in their proper locale formats without me having to explicitly do this.
Now why is this failing? In some languages upper and lower case letter apparently have different meanings and they don’t quite refer to the same thing. I’m not familiar with the Turkish Alphabet treatment, but I seem to remember from a localization lecture a long while back that some alphabets treat upper and lower case differently.
What’s odd is that there are several other field accesses prior to this one and all of those actually work fine. However, this is the only field that starts with an I.
The code for the field values is generated so the fix in this case is easy – just re-generate the code and force all lower case characters. Nevertheless this is a very scary proposition, which is now making me think hard about using visitor language impersonation on my requests.
I’m just running through my entire app with the Turkish browser setting and since every request automatically switches locale it’s interesting to see all the places code is broken due to this particular bug. It’s not just DataRows, but also table names in DataSets – basically anything with a string based indexer has a potential problem with this code.
Learn something new every day.
The Voices of Reason
# re: DataRows, String Indexes and case sensitivity with Turkish Locale
I'm not sure what the real solution is. Actually it turned out that my quick fix wasn't quite enough. I have lots of instances of indexed properties that start with an I like DataSet table references etc. It's really hard to be consistent with that.
I'm fairly confident though that forcing lower case on indexes would solve this problem. But it's a bit unrealistic after the fact <g>...
The other solution is to turn off the thread locale switching. With that off the error disappears completely as well. The alternative would be to fix up any data and numeric values manually.
Maybe somebody from Turkey can clarify how the alphabet works and most importantly how they deal with indexed values in their applications. I would guess they are more disciplined <g>.
# re: DataRows, String Indexes and case sensitivity with Turkish Locale
# re: DataRows, String Indexes and case sensitivity with Turkish Locale
basically, there is a case sensitive index and a case insensitive index and they don't always seem to get updated...
solution is to copy the dataset to itself with ds=ds.Copy()
I don't know if you can do this with DataRows though.
http://www.kbalertz.com/kb_815545.aspx
# re: DataRows, String Indexes and case sensitivity with Turkish Locale
Interesting, but that's an unrelated problem. The issue here is clearly that the letter I has a different meaning in upper and lower case in the Turkish alphabet. Most other fields work fine in mixed case.
# re: DataRows, String Indexes and case sensitivity with Turkish Locale
along with a very similar error
-------Begin Error-------
/webstore/item.aspx?sku=MLA-5-50
Column 'Image' does not belong to table wws_items.
on 15.03.2005 14:55:46
--- Stack Trace ---
at System.Data.DataRow.get_Item(String columnName)
at DataRowContainers.wws_itemsRow.get_Image()
at Westwind.WebStore.Item.DisplayItem() in w:\wwWebStore\item.aspx.cs:line 129
at Westwind.WebStore.Item.Page_Load(Object sender, EventArgs e) in w:\wwWebStore\item.aspx.cs:line 57
at System.Web.UI.Control.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain()
--- Request Information ---
Full Url: http://www.emproshunts.com/webstore/item.aspx?sku=MLA-5-50
IP: 81.214.122.121
Referer: http://www.emproshunts.com/webstore/ItemList.aspx?Category=MLA
Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; SV1)
Login: Anonymous
-----end Error--------
I went and did an IP look up, its from Turkey
If you want me to i can compare my error logs to geo location..
Now your going to love this from confirmed ips comming from turkey their are a total of 61 hits there is a total of 64 errors on the server????
that matches a little to close ????
# re: DataRows, String Indexes and case sensitivity with Turkish Locale
To distinguish, the capital letter I (with the dot) also has a dot. Thus, in Turkish, I (without the dot) is not the capital version of i, but is the capital version of i (without the dot).
I suspect that somewhere along the way, the case-sensitivity of the key is being removed. When, it is re-applied, then, the wrong I (the one without the dot) is being used.
# re: DataRows, String Indexes and case sensitivity with Turkish Locale
# re: DataRows, String Indexes and case sensitivity with Turkish Locale
ur right about the turkish language problem. even i m faced with a similar problem.
there is a link which does mention about this in msdn but no solution to solve it except tht not to use casing with these cultures.. a bit too late for us i think :-)
http://msdn.microsoft.com/msdnmag/issues/05/03/CultureInfo/default.aspx
regards
Vishal
# re: DataRows, String Indexes and case sensitivity with Turkish Locale
I noticed one day that I could not log into my website and got this error: "column somethine does not...".
But when I tried this from my local version of the site this didn't happen.
Both the local and the hosted version were connecting to the same SQL server that is hosted at the same company as the website.
How is this possible, and this happens only occasionally ?
Is this the same problem you were facing or a problem with the hosting itself ?
# re: DataRows, String Indexes and case sensitivity with Turkish Locale
But what if there's another language which turns out to need "I" or some other letter in uppercase?