June 7, 2013 at 9:16 am
WWDMark (6/6/2013)
I was wondering about the collation issue (i.e. case sensitive or not) and as the question didn't specify the collation I took a punt...... and got it wrong! Hey Ho. 😀
+1
June 7, 2013 at 2:26 pm
why does 'r ' = 'R'
this is like saying Length or 2 = Length of 1
in the problem it is small r + a blank space set = capitol R
Length of the left side is 2 <> Length of the right side of 1
therefore it should answer no
not yes
why is this not true?
June 7, 2013 at 2:27 pm
why does 'r ' = 'R'
this is like saying Length or 2 = Length of 1
in the problem it is small r + a blank space set = capitol R
Length of the left side is 2 <> Length of the right side of 1
therefore it should answer no
not yes
why is this not true?
June 7, 2013 at 2:34 pm
eric larocca (6/7/2013)
why does 'r ' = 'R'this is like saying Length or 2 = Length of 1
in the problem it is small r + a blank space set = capitol R
Length of the left side is 2 <> Length of the right side of 1
therefore it should answer no
not yes
why is this not true?
Please read the posts already made, as they answer this question. If anything is unclear after reading the existing discussion, feel free to ask.
June 11, 2013 at 1:45 pm
Hugo Kornelis (6/6/2013)
Joseph M. Morgan (6/6/2013)
The first string has a space after the letter, the second does not. Without a Trim, why are they equal? Case sensitivity is irrelevant. The two strings aren't equal.Trailing blanks are trimmed before string comparison. This is documented in Books Online.
What I am wondering, though, is why the question explicitly introduces both lowercase and uppercase. I now had to take a 50% gamble as to the default collation used by the author's server. Why not either use the same case for both, or explicitly specify the collation?
+1
June 13, 2013 at 5:08 am
L' Eomot Inversé (6/6/2013)
michlimes (6/6/2013)
default collation is choosen at installation process - so imo it could be CS_AS.You can override the installation defaults when doing the installation. Then you don't have a default installation any more, you have a non-default one. So the word "default" is a bit ambiguous - the server default in your instance is not the installation default.
However, I think you are right to suggest that the collation should always be specified in a QotD when it is relevant.
I think I've seen in the discussions of previous questions that where something isn't specified it's reasonable to assume the system has been set up with installation defaults. That's the way I read this and, from a previous QotD, I know the installation default is case insensitive so I got this right.
However, there are an awful lot of installation defaults that I don't know so I agree it would useful to have anything that applies to a QotD to be stated positively at the start.
June 18, 2013 at 2:37 pm
Thanks for the question Ron.
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
June 19, 2013 at 1:38 am
I was wondering why so many questions regarding the collation. In a normal scenario it should be considered as the default behaviour for the question which is CI (and not CS). I feel it was a great example of simple QOTD. 🙂
June 19, 2013 at 2:01 am
sqlnaive (6/19/2013)
In a normal scenario it should be considered as the default behaviour for the question which is CI (and not CS).
I disagree, and I'll tell you why.
In questions where collation is not a factor, using the consistent case throughout the question prevents ambiguity. If you ensure the question works okay onm a CS collation, it will also be okay on a CI collation. The reverse is not true. So writing the question for a CS collation is the best way to ensure that everyone has a fair chacne - including those who are aware that not all SQL Server instances in the world are installed on a CI collation.
And in questions where collation is a factor, the collation should always be included in the question, so there can never be a problem there.
June 19, 2013 at 4:06 am
Agreed Hugo. That should be the case ideally. However probably I was not clear. What i wanted to say here was that the emphasis should be given based on the question's subject. As in this scenario the question was for IFF category in SQL 2012 environment. The different cases of value ('r' or 'R') may raise doubt in mind but in such case obviously we should go with default settings. Maybe I'm thinking too liberal on this. 🙂
June 19, 2013 at 11:48 am
Hugo Kornelis (6/19/2013)
sqlnaive (6/19/2013)
In a normal scenario it should be considered as the default behaviour for the question which is CI (and not CS).I disagree, and I'll tell you why.
In questions where collation is not a factor, using the consistent case throughout the question prevents ambiguity. If you ensure the question works okay onm a CS collation, it will also be okay on a CI collation. The reverse is not true. So writing the question for a CS collation is the best way to ensure that everyone has a fair chacne - including those who are aware that not all SQL Server instances in the world are installed on a CI collation.
And in questions where collation is a factor, the collation should always be included in the question, so there can never be a problem there.
Although I agree that it is probably a good idea to specify the collation when it is relevant (i.e. when it affects the answer to the question) I also have my doubts about it. After all, case-sensitive collations are an absolute pain for almost all purposes, so it might be a good idea to get people whose servers are set up with case-sensitive collations to suffer a little extra pain in QOTD in the hope that this might encourage them not to use the horrible things in the future. :hehe::w00t::hehe:
Tom
June 19, 2013 at 2:53 pm
L' Eomot Inversé (6/19/2013)
After all, case-sensitive collations are an absolute pain for almost all purposes, so it might be a good idea to get people whose servers are set up with case-sensitive collations to suffer a little extra pain in QOTD in the hope that this might encourage them not to use the horrible things in the future. :hehe::w00t::hehe:
A production server should be installed with the collation that best fits the application(s) it will support. If that means case sensitive, than that is the best collation, and not a horrible thing at all.
A dev server that is used to develop for deployment on a specific server should be installed with the same collation as where the code will eventually be deployed.
And dev servers that are used to develop code that may be deployed "anywhere" should always be installed with case sensitive collations, as that avoids making mistakes taht can be very costly (and a royal pain in the backside) to fix later. If your dev server is case sensitive, you'll get slapped immediately when messing up the case of object names, and you'll soon learn not to make those mistakes. If your dev server is case insensitive, you will, eventually, get sloppy with upper- and lowercase. And you will not notice that, not even get a warning, during any of your tests. Even your first deployments may go right - until your database is sold to a customer who is running SQL on a case sensitive collation, and he reports errors all the time. Fun! (not!)
So, I guess I do not agree with you. 😎
June 20, 2013 at 1:01 am
Hugo Kornelis (6/19/2013)
L' Eomot Inversé (6/19/2013)
After all, case-sensitive collations are an absolute pain for almost all purposes, so it might be a good idea to get people whose servers are set up with case-sensitive collations to suffer a little extra pain in QOTD in the hope that this might encourage them not to use the horrible things in the future. :hehe::w00t::hehe:A production server should be installed with the collation that best fits the application(s) it will support. If that means case sensitive, than that is the best collation, and not a horrible thing at all.
A dev server that is used to develop for deployment on a specific server should be installed with the same collation as where the code will eventually be deployed.
And dev servers that are used to develop code that may be deployed "anywhere" should always be installed with case sensitive collations, as that avoids making mistakes taht can be very costly (and a royal pain in the backside) to fix later. If your dev server is case sensitive, you'll get slapped immediately when messing up the case of object names, and you'll soon learn not to make those mistakes. If your dev server is case insensitive, you will, eventually, get sloppy with upper- and lowercase. And you will not notice that, not even get a warning, during any of your tests. Even your first deployments may go right - until your database is sold to a customer who is running SQL on a case sensitive collation, and he reports errors all the time. Fun! (not!)
So, I guess I do not agree with you. 😎
The only advantage of case-sensitive collation is that programmers should write statements with the right case. But changing a collation for an application never is a good idea. Swithing CI with CS or viceversa leads to many problems.
I work with both: old thirdy-part application uses CI and the new one CS.
I prefer case INSENSITIVE.
July 2, 2013 at 1:56 am
L' Eomot Inversé (6/6/2013)
michlimes (6/6/2013)
default collation is choosen at installation process - so imo it could be CS_AS.You can override the installation defaults when doing the installation. Then you don't have a default installation any more, you have a non-default one. So the word "default" is a bit ambiguous - the server default in your instance is not the installation default.
However, I think you are right to suggest that the collation should always be specified in a QotD when it is relevant.
Here here!
July 12, 2013 at 6:32 am
an easy one and so much explanations for a so little problematic
Viewing 15 posts - 31 through 45 (of 45 total)
You must be logged in to reply to this topic. Login to reply