by Michael S. Kaplan, published on 2006/10/30 04:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/10/30/897681.aspx
(this post is not about relationship advice!)
Regular reader Dean Harding pointed out a few days ago when I talked about When collations collide?:
Yeah, this is a real problem when you're developing an application that can be installed on somebody else's instance of SQL Server.
You basically HAVE to develop it on a case-sensitive instance locally, otherwise one of your users invariably has a case-sensitive instance installed and your app breaks. They get upset if you tell them to install it on a new instance that is not case-sensitive :)
I couldn't agree with this point more, and not only because I suggested the same thing in the post Case/kana/accent/width sensitive SQL Server, for testing back from May of last year. :-)
The reason why case/kana/accent/width sensitivity finds more bugs is actually kind of a cultural issue for people who do database work as opposed to programmers.
In database design there is not usually as much of a conscious effort to use that case sensitivity as a differentiation feature -- so that if you use the uppercase vs. lowercase vs. capitalized version of an identifier, it is more likely to be bug in the actual application, if something does not work, rather than explicit attempt to use multiple forms.
Now this is in sharp contrast to some programming language cases, where (for example) it is not uncommon to see developers who use specific conventions like "lowercasing of internal variables/parameters vs. proper casing/camel casing for public properties/methods" where the "collision" one would find in a case insensitive environment would be intentional. And of course in programming languages one cannot usually flip a setting to change the behavior like one can do with SQL Server -- one's choice is implicit in one's language decision.
Of course if one is providing a database or stored procedure or UDF or sample in SQL Server, ideally one will test both scenarios since it is impossible to know where the information will be used. But if one has to choose, being more sensitive will (in the end) reveal more problems, which makes it a better choice....
(Which is also probably true of relationships, though I am the last person in the world who one should be listening to on that score!)
This post brought to you by Ꮺ (U+13ea, a.k.a. CHEROKEE LETTER WE)
# Dean Harding on 30 Oct 2006 7:00 AM:
Where I work at the moment, we have an all-lowercase naming convention for database sprocs, table names, column names and so on, which seems to hold up better in the face of going case-sensitive. My last job had a CamelCase convention, and incorrect casing was all-too-common.
I guess it's just because IntelliSense makes us too lazy in the development environment, and because it "just works" in a case-insentive database, there's little reason to be vigilent.
Until, of course, you get that customer who wants to run your app in a case-sensitive database (for whatever reason) and it doesn't work!!
# Phylyp on 30 Oct 2006 10:17 AM:
> Which is also probably true of relationships, though I am the last person in the world who one should be listening to on that score!
Heh, I'm sitting here contemplating a relationship that just ended, and I'm wondering what the hell happened, what went wrong? You're advice is late for that relship, early for the next one :)
# Michael S. Kaplan on 30 Oct 2006 3:22 PM:
Hey Dean,
So did they mix different case styles in the app, or was it always all one or all the other (that has been my experience on tha database side)?
# Dean Harding on 30 Oct 2006 6:03 PM:
It was pretty consistently CamelCase in the database (variables an columns are differentiated by the fact that variables start with an @). Though in code it was public-properties/fields are CamelCase, private fields are lowerFirstChar.
My guess is that people just got lazy because it worked properly without proper casing - at least in the IDE it fixed up incorrect case automatically with IntelliSense.
referenced by