May 2, 2013 at 5:57 am
Hugo Kornelis (5/2/2013)
However, to do some nitpicking:1. If I were to try this code on my system, I would get five errors. All system table (*) names are completely lowercase, so everyone who has a server set up with a case sensitive collation will get error messages. (And I think every development server SHOULD be set up with case sensitive collation - developing there and deploying to a case insensitive server is okay, the other word around is a disaster)
Not necessarily true. If your development server is case sensitive you run the risk of having more than one object with the same name, only with different casing. When deploying on a case INsensitive server it will blow up.
May 2, 2013 at 6:12 am
Rune Bivrin (5/2/2013)
Hugo Kornelis (5/2/2013)
However, to do some nitpicking:1. If I were to try this code on my system, I would get five errors. All system table (*) names are completely lowercase, so everyone who has a server set up with a case sensitive collation will get error messages. (And I think every development server SHOULD be set up with case sensitive collation - developing there and deploying to a case insensitive server is okay, the other word around is a disaster)
Not necessarily true. If your development server is case sensitive you run the risk of having more than one object with the same name, only with different casing. When deploying on a case INsensitive server it will blow up.
Technically true. Realistically, the chance of this happening by accident is a lot smaller than the chance of using wrong case on a case insensitive server.
May 2, 2013 at 6:17 am
Rune Bivrin (5/2/2013)
Hugo Kornelis (5/2/2013)
However, to do some nitpicking:1. If I were to try this code on my system, I would get five errors. All system table (*) names are completely lowercase, so everyone who has a server set up with a case sensitive collation will get error messages. (And I think every development server SHOULD be set up with case sensitive collation - developing there and deploying to a case insensitive server is okay, the other word around is a disaster)
Not necessarily true. If your development server is case sensitive you run the risk of having more than one object with the same name, only with different casing. When deploying on a case INsensitive server it will blow up.
+1
Why should you choose CASE SENSITIVE COLLATION?
Please, do not answer for performance reason!
May 2, 2013 at 7:15 am
Hugo Kornelis (5/2/2013)
Rune Bivrin (5/2/2013)
Not necessarily true. If your development server is case sensitive you run the risk of having more than one object with the same name, only with different casing. When deploying on a case INsensitive server it will blow up.Technically true. Realistically, the chance of this happening by accident is a lot smaller than the chance of using wrong case on a case insensitive server.
It seems more likely to me than the chance of having code deployed to a case sensitive server without having been previously informed that case sensitivity was a business requirement. Case sensitive strikes me as an annoyingly persnickity environment to code in though, so I may be biased.
May 2, 2013 at 7:59 am
Thanks for the question, some people tend to forget the basics and waste time chasing their tales. Whether you use system tables, depricated or user tables you proved your point.
May 2, 2013 at 9:16 am
This was removed by the editor as SPAM
May 2, 2013 at 10:02 am
Thanks for the easy question.
-Tracie
May 2, 2013 at 10:32 am
Really nice one - thanks!
May 2, 2013 at 11:08 am
EZ PZ Lemon Squeezy
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
May 2, 2013 at 2:55 pm
Hugo Kornelis (5/2/2013)
(And I think every development server SHOULD be set up with case sensitive collation - developing there and deploying to a case insensitive server is okay, the other word around is a disaster
I think I'll add that one to my list of dangerous T-SQL myths. If someone has used a case-sensitive server for development and distinguished betwen the 8 columns COL, COl, CoL, Col, cOL, cOl, coL,and col deployment to a case-insensitive server will be a disaster, far from OK. I am sure that you know better Hugo, and don't understand why you make such a silly statement.
Personally, I think using a case insensitive collation as the default is best practise. Obviously case sensitivity is required for comparing strings in some rare cases, but there's nothing wrong with specifying a case sensitive coolation in those rare cases; the cases where string comparison needs to be case insensitive are, I believe, far more frequent.
Tom
May 2, 2013 at 2:58 pm
Hugo Kornelis (5/2/2013)
Rune Bivrin (5/2/2013)
Hugo Kornelis (5/2/2013)
However, to do some nitpicking:1. If I were to try this code on my system, I would get five errors. All system table (*) names are completely lowercase, so everyone who has a server set up with a case sensitive collation will get error messages. (And I think every development server SHOULD be set up with case sensitive collation - developing there and deploying to a case insensitive server is okay, the other word around is a disaster)
Not necessarily true. If your development server is case sensitive you run the risk of having more than one object with the same name, only with different casing. When deploying on a case INsensitive server it will blow up.
Technically true. Realistically, the chance of this happening by accident is a lot smaller than the chance of using wrong case on a case insensitive server.
If something is case insensitive there is no possible real world referent for "wrong case". So how is the chance of using the "wrong case" different from zero?
Tom
May 2, 2013 at 3:37 pm
+1 🙂
Not all gray hairs are Dinosaurs!
May 2, 2013 at 4:42 pm
L' Eomot Inversé (5/2/2013)
Hugo Kornelis (5/2/2013)
(And I think every development server SHOULD be set up with case sensitive collation - developing there and deploying to a case insensitive server is okay, the other word around is a disasterI think I'll add that one to my list of dangerous T-SQL myths. If someone has used a case-sensitive server for development and distinguished betwen the 8 columns COL, COl, CoL, Col, cOL, cOl, coL,and col deployment to a case-insensitive server will be a disaster, far from OK. I am sure that you know better Hugo, and don't understand why you make such a silly statement.
Personally, I think using a case insensitive collation as the default is best practise. Obviously case sensitivity is required for comparing strings in some rare cases, but there's nothing wrong with specifying a case sensitive coolation in those rare cases; the cases where string comparison needs to be case insensitive are, I believe, far more frequent.
+1000. Becoming a slave to case sensitivity is a bit insane especially since MS itself has NOT adopted a reasonable naming convention for any objects be it a table name, a column name, or what have you. There are actually very few things that need to be case sensitive. Isolate those things at table design time and make only those columns case senstive. The fact that things like Intellisense perpetuate the poor casing is no good reason for having a case senstive server.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 3, 2013 at 6:55 am
Nice question on the fundamentals... thanks for it.
May 3, 2013 at 8:03 am
Thanks for the easy question! Good back to basics one.
Viewing 15 posts - 16 through 30 (of 32 total)
You must be logged in to reply to this topic. Login to reply