May 21, 2010 at 7:16 am
How archaic is talking some one through code?
Try talking someone through typing a web address that uses something beyond the .com!
"use the forward slash here, the one next to the question mark key"
This issue goes way beyond the limited topic here, try working a network help desk sometime...
May 21, 2010 at 8:03 am
Your comment about how to convey the curly braces, square brackets, etc., verbally made me stop and think . . . suppose you had been dealing, via video conference, with someone who was deaf and you had to convey everything via sign language. How do you sign "curly brace"? ;-):-P:hehe:
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 21, 2010 at 8:35 am
Hugo Kornelis (5/21/2010)
While I mostly agree with the sentiment expressed in the editorial, there is one place where I don't. Where, in fact, I'd even reverse the statement:"There really is little justification for not having a case-sensitive collation for database on a dev server"
When developing code, you can never be entirely sure what server(s) it will be deployed on. One of them could be neglecting Phil's good advice and using a case sensitive collation. And surely, you would not want your deployment fail because users get bucketloads of "Table cUstOMer not found" errors, because the table is acutally called "CusTOmeR".
Make sure you always develop and test on a case-sensitive server, and you'll never have these problems.
(And an added benefit is that you don't get the confusion sometimes caused by using different case for the same object in the same query).
Agreed, and I guess it is all what you have been used to too. I started out using the C Programming language so using case-sensitivity is not that big of a deal for me personally. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
May 21, 2010 at 9:24 am
Phil Factor (5/21/2010)
"There really is little justification for not having a case-sensitive collation for database on a dev server"
Hugo, I heartily agree with the sentiment, but I hate to actually recommend having a case-sensitive DEV machine because developers tend to get bored with correcting errors in their perfectly sensible mixed-case object names and just do everything in lower case. I've seen it happen so many times. It is precisely what you want to avoid. What we need instead is a utility that takes the original names in the metadata, complete with their original capitalisation, and creates a script that corrects the case of the names elsewhere in all the code that references the object, according to the original definition. Hmm... Maybe I shall write such a thing. I'm hopeless at remembering capitalisation, which is why I'm hopeless at JavaScript (or is it Javascript?)
There are two cases (!) of case-sensitivity: the SQL and such and the data in the database. Windoze and SQLServer, last I looked, were still insensitive for data. Languages do what they want. Insensitive data, for any sensible commercial/business application, is what's desired. Smith and SMith as well as McMurray and MCMurray should sort together. Unix derived engines generally are Sensitive, in all that means.
Since the encodings (in ASCII anyway, the BCD/EBCDIC story is worser) exist separately, it is just less work for systems programmers (and DB engine writers are such) to take the encodings as-is; M$ did the work, while the Multics/Unix folk didn't.
May 21, 2010 at 9:40 am
This is like playing Jepordy!
My answer to the Daily Double is:
"Why they wrote COBAL and why it failed."
Does anyone actually remember why they wrote COBAL? I know it was case sensitive like most code from the dark ages.
The concept truely was a language that Business users could understand with a command base that could be shouted across a noisy server room through a bad telco connection.
This worked great until managers and users thought they understood the code and language so well they started writing thier own COBOL applications. How hard could it be?
Fast forward 20 to 30 years and now everyone large business that ever used COBOL has a bad story about not being able to use or convert some poorly structured COBOL app that an Accountant/Manager wrote and then left.
Hrmmmm I make money converting bad legacy apps and data to new low cost managable .NET and MS SQL solutions.
GO COBOL!
May 21, 2010 at 10:18 am
We have done as you suggest for over 20 years and do not use case sensitive unless it is COTS software. No need for it.
However the yelling of code and solutions should be questioned. As one who has been involved with security for some time it has been noted that this practice is at best questionable when dealing with certain aspects of the business. And when it is done with any code or solution it becomes a practice is happens in cases where it should not.
I agree that things should be easier. They are now far easier. But to make them so simple and open that they lack security and at least a little trickery to keep the vermin out needs some rethinking.
Still the basic idea is fine. Just be careful.
Not all gray hairs are Dinosaurs!
May 21, 2010 at 10:22 am
jparker2 (5/21/2010)
This is like playing Jepordy!My answer to the Daily Double is:
"Why they wrote COBAL and why it failed."
Does anyone actually remember why they wrote COBAL? I know it was case sensitive like most code from the dark ages.
The concept truely was a language that Business users could understand with a command base that could be shouted across a noisy server room through a bad telco connection.
This worked great until managers and users thought they understood the code and language so well they started writing thier own COBOL applications. How hard could it be?
Fast forward 20 to 30 years and now everyone large business that ever used COBOL has a bad story about not being able to use or convert some poorly structured COBOL app that an Accountant/Manager wrote and then left.
Hrmmmm I make money converting bad legacy apps and data to new low cost managable .NET and MS SQL solutions.
GO COBOL!
COBOL, at least on IBM systems, is not case sensitive. Mixed case is allowed for human readability but all code is converted to upper case when compiled.
May 21, 2010 at 10:37 am
Unless we can devise special sounds for curly brackets (open and close), semi-colons and maybe an altered intonation for upper-case
Funny you should mention that, especially since you are in Cambridge. Back in the day when I was reading Computer Science at Cambridge (long enough ago that Prof Wilkes was still head of department, and Andy Hopper was just a Wild Young Man), one Rag Week we read the whole of the Backus Naur syntax for Algol 68, mostly in the Market Square (displacing several innocent drunks from the fountain). Interpretation of the special punctuation in BNF and A68's special symbols was was left to the individual, and boy did we "interpret" them.
May 21, 2010 at 10:50 am
I completely disagree. If you can't stand the heat, get out of the kitchen.
There is too much "lets make it fair for everyone" in this country, and this sounds too much like that. Every database is different. It is why we get paid to do what we do. I have databases that are case sensitive, and others that are not. When I code in the ones that are, I make sure to type things correctly. When coding in ones that aren't, I sometimes use shortcuts and use all lowercase identifiers. That code looks poor compared to the systems that are case sensitive, so I actually prefer case sensitivity. It makes me think of writing good code which is a significant benefit.
It doesn't matter if a manager can code something, he or she should not code if they are not skilled. If something is critical, I can remote in and fix it. I realize some companies may be in worse shape than we are with no backup plan if the DBA is gone, but you can't design a database to make it easier for a non DBA to handle an emergency at the expense of proper design considerations.
While I work primarily with SQL Server, keep in mind that a lot of DBAs support both Oracle and SQL Server, and Oracle is frequently on Unix/Linux systems that are case sensitive. There is frequently a need to share data between these systems, where case sensitivity would be critical.
If case sensitivity wasn't necessary in certain situations it would be deprecated.
Dave
May 21, 2010 at 10:51 am
Ewan Hampson (5/21/2010)
Unless we can devise special sounds for curly brackets (open and close), semi-colons and maybe an altered intonation for upper-case
Not sure about upper/lower case, but Victor Borge's phonetic punctuation could fit the bill... (I can't check out video/audio links at work, but you know where to search...)
That's the first think I thought of when I read the editorial. One example can be found on YouTube.
May 21, 2010 at 10:53 am
I haven't coded in VB for a few years (VBSciprt only currently) but what if I want a variable named MyNewVariable and another one named MYNewVariable? Yes, that would most likely be a poor design - but what would the result be?
Dave
May 21, 2010 at 10:55 am
C is an abomination? Have you seen java?
Dave
May 21, 2010 at 10:58 am
djackson 22568 (5/21/2010)
I completely disagree. If you can't stand the heat, get out of the kitchen.There is too much "lets make it fair for everyone" in this country, and this sounds too much like that.
And which country is that? There's a fair chance Phil Factor is in a different one than you.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
May 21, 2010 at 10:58 am
djackson 22568 (5/21/2010)
I haven't coded in VB for a few years (VBSciprt only currently) but what if I want a variable named MyNewVariable and another one named MYNewVariable? Yes, that would most likely be a poor design - but what would the result be?
My apologies for not understanding the "quote" option...
This is in regards to "Back on point, case sensitivity is an artifact of C. Period. Too many programmers learned that abomination of a language ..."
Dave
May 21, 2010 at 11:26 am
For djackson -Now you're making me think - a dangerous thing most times.
I don't know why you'd want a variable that is so much the same - it would make the code hard to read and debug.
VB considers MyNewVariable and MYNewVariable the same and won't compile. VBScript is just a subset of VB and unless you are using a decent editor, VBSEdit comes to mind, you get a 'Name Redefined' run time error.
Try the following code to get the error:
Dim MyNewVariable
Dim MYNewVariable
MyNewVariable = "Cased"
MYNewVariable = "CAsed"
msgbox(MyNewVariable & " " & MYNewVariable)
Then Rem out the MYNewVariable lines and try it again - you should get the message box saying Cased Cased, even if you dont change that line.
VBScript isnt strongly typed - you don't have to tell it what data type to use - You can download the Express edition ov VB for nothing too. It has a lot of good data access tools that make usng things like stored procedures easy.
Viewing 15 posts - 16 through 30 (of 52 total)
You must be logged in to reply to this topic. Login to reply