If you don't always preserve case, you don't always preserve meaning

by Michael S. Kaplan, published on 2007/06/18 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/06/18/3374502.aspx


You may recall last week when I mentioned that In any CASE, it is somewhat INSENSITIVE to point out to someone how well PRESERVED they are.

Those words are very true, by the way -- I would suggest never trying that!

In any case, just the other day, Marý from Iceland actually pointed out a situation that actually shows some really negative consequences of NOT preserving case. She pointed out:

Hi,

I was just reading your post about the Danish/Norwegian collation sorting problems from April 27th. I am having considerable problems with the collation myself but it doesn't have anything to do with the sorting but more to do with the SQL statements themselves. If I send a SQL statement to the server that has mixed case in it and one of the words happens to have an aA in it (for example: Select * From Table Where DataArea = 'dat') then the server changes the aA to an å before executing the statement and therefor the statement doesn't execute at all but if I change the statement to be either uppercase or lowercase it works just fine.

I'm from Iceland and we've got loads of weird letters of our own and I've never had this problem on our own collation. I suppose the argument can be made that you should only send statements in uppercase to the SQL server - but I find it extremely odd that the SQL server would assume that all SQL statements are in either uppercase or lowercase.

Anyway I'm just wondering if in your research you've seen anything relating to this. The only thing I've ever found on this has to do with the sorting - not the SQL statements themselves. I'm using C# and SQL Server 2005

With thanks,
Marý Björk

The post Marý was referring to was The disunification of Norwegian and Danish sorting.

And yes, it is true that Icelandic does not have any of these interesting conventions involving the ASCII-fication of letters like Norwegian and Danish used to have (and only one still does, by convention!).

The problem Marý is hitting here is in fact caused by someone not preserving case distinctions and running headlong into the Microsoft convention for compressions in sorting. And some component's lack of respect for it.

But if there is a component that is converting the query to either all capital letters or all small letters, then that operation actually changes the meaning of the text in the query, in this case.

Which is pretty lame, any way you look at it.

After all, in Marý's example, it is failing on an actual column name's identification and use. And this problem can happen on both case sensitive and case insensitive SQL Server databases/servers.

I am offhand hoping that this is NOT the server that is screwing this up, but one of the layers in between the C# code and the server (precisely which one is not something I am certain of, since the exact method was not specified).

Probably the next step would be to try and isolate what might be doing this.

Marý, any more info on how you are running the query (bound grid, ADO, LINQ, ADO.Net, or other)?

It would be nice to find out who is being lame here! :-)

 

This post brought to you by ý (U+00fd, a.k.a. LATIN SMALL LETTER Y WITH ACUTE)


no comments

referenced by

2007/10/24 Getting the preserved case of a file wHeN tHe uSeRs tYpE wHaTeVeR tHe hElL tHeY wAnT tO

2007/10/24 In Case you have problems that you might think are ǸȦȘȚȲ

2007/10/02 What happens when people don't consistently preserve case? They cause bugs!

2007/09/23 If it isn't Unicode, it isn't ANY code!

2007/09/18 A&P of Sort Keys, part 8 (aka You can often think of ignoring weights as a form of ignorance)

2007/09/05 Head checks containing either comparison or case validation BITE

2007/08/21 In Case there is a bug....

go to newer or older post, or back to index or month or day