May 24, 2010 at 7:31 am
If both variables were in the same scope, they would be the same variable. If they were different scopes (say local to two different subs or functions) they would be different variables.
May 24, 2010 at 7:42 am
Oops, sorry - hadn't done a quoted reply yet. I guess I can put my foot in my mouth faster than most folks. I hadn't taken scope into account and I often use the same variable names in subroutines and functions - ds for DataSet, X or i for a counter in a for loop, whatever. Saves me from having to think up new variable names too.
May 24, 2010 at 7:46 am
Case-sensitive collation for a database (ex: 'John Smith' <> 'JOHN SMITH'), case-sensitive programming languages (Main != main), and case-sensitive string comparisons within a programming language ("John Smith" != "JOHN SMITH") are 3 completely different issues.
A development environment can have a mix and match of any of the above. The article started off talking about case-sensitive database collation, but then seemed to digress into case-sensitive programming languages.
By the way, please don't yell database management commands across the room to one your co-workers who is sitting at a remote console for the production database server.
Especially not when the SOX auditors are on site!!!
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 24, 2010 at 8:17 am
RobertYoung (5/24/2010)Since ASCII (BCD/EBCDIC is another kettle of fish) is cased, they would have to write routines to un-case the encoding wherever. It's so much easier to let it be.
I'm not sure whether you are trying to imply that EBCDIC only has one case of characters or what; however, both ASCII and EBCDIC have distinct upper and lower case characters. For instance, ASCII has A coded as (decimal) 41 and a as 61. The corresponding values for EBCDIC are 193 and 81, respectively. In procedural code, in order to code for case insensitivity, you have to either convert the data to one case( either all upper or all lower) or code comparisons that test for testing both ("CharString[x] = 'A' OR CharString[x] = 'a'") and that is probably pretty much what is done in the database engine. Having said that, I have mixed feelings about Case Sensitive collations. They do become a bit of a pain when someone is mixing the case used in inserting or updating data.
As for BCD, if you are referring to Binary Coded Decimal . . . well, I don't ever remember numerics as having what one would call "case".
Ralph D. Wilson II
Development DBA
"Give me 6 hours to chop down a tree and I will spend the first 4 sharpening the ax."
A. Lincoln
May 24, 2010 at 8:28 am
RalphWilson (5/24/2010)
RobertYoung (5/24/2010)Since ASCII (BCD/EBCDIC is another kettle of fish) is cased, they would have to write routines to un-case the encoding wherever. It's so much easier to let it be.
I'm not sure whether you are trying to imply that EBCDIC only has one case of characters or what; however, both ASCII and EBCDIC have distinct upper and lower case characters. For instance, ASCII has A coded as (decimal) 41 and a as 61. The corresponding values for EBCDIC are 193 and 81, respectively. In procedural code, in order to code for case insensitivity, you have to either convert the data to one case( either all upper or all lower) or code comparisons that test for testing both ("CharString[x] = 'A' OR CharString[x] = 'a'") and that is probably pretty much what is done in the database engine. Having said that, I have mixed feelings about Case Sensitive collations. They do become a bit of a pain when someone is mixing the case used in inserting or updating data.
As for BCD, if you are referring to Binary Coded Decimal . . . well, I don't ever remember numerics as having what one would call "case".
Here's the BCD character set:
http://www.thinkage.ca/english/gcos/expl/bcd.html
There is an difference in how a systems programmer can de-case ASCII and EBCDIC: in ASCII the alphas are contiguous, so it's just one range substitution; easy. With EBCDIC, being derived from BCD and card punches, the alphas exist in multiple ranges due to the use of the zone punch. So, not quite so easy.
May 24, 2010 at 8:29 am
Phil did start talking about database collation, and then wished for a computer language for 'real work'.
And the byline to the article is -
"Just because mistakes have become entrenched in the computer languages that we use doesn't mean we have to tolerate them "
But since this is a SQL forum - I am VERY grateful that 'Select MyColumn from MyTable' is the same thing as 'SElect MyColumn from MyTable' or 'Select MYColumn from MYTable'
May 24, 2010 at 8:43 am
This immediately prompted memories of taking an online video course in SQL 2005. The instructor had made up his own nicknames for punctuation:
/ = "Whack"
* = "Splat"
. = "Dot" (of course)
: = "Doink"
{ or } = "Squiggle" (the direction was based on context, or specified as "open squiggle" or "close squiggle"
[ or ] = "Box"
! = "Bang" (of course)
? = "Wokka" (Fozzy Bear = ???)
etc etc.
It almost made me want to go through ALL of his videos just to build a full phonetic language for symbols...
...almost.
May 24, 2010 at 9:01 am
dcraday (5/24/2010)
But since this is a SQL forum - I am VERY grateful that 'Select MyColumn from MyTable' is the same thing as 'SElect MyColumn from MyTable' or 'Select MYColumn from MYTable'
For the last few years, I code all of my SQL and object names in lower case, using underscore for noun seperation instead of capitalization. For example sales.person, sales.contact, sales.person_contact. Coding in CAPS brings back memories of COBOL and FoxPro, and coding in ProperCase imposes an obligation, forcing one to choose between either anal retentivness or inconsistency. After writing a block of T-SQL code, I'll highlight it, comments and all, and do a <shift><ctrl><L> just to insure that any inadventent capitalization is switched to lower case.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 8 posts - 46 through 52 (of 52 total)
You must be logged in to reply to this topic. Login to reply