|
|
Posted by Steve on 11/08/07 16:23
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:8YCdndIBAbkzsq7anZ2dnUVZ_hmtnZ2d@comcast.com...
> Steve wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>> news:192dnW2kIL6akq7anZ2dnUVZ_sjinZ2d@comcast.com...
>>> Steve wrote:
>>>> "The Natural Philosopher" <a@b.c> wrote in message
>>>> news:1194484441.81272.6@demeter.uk.clara.net...
>>>>> Darko wrote:
>>>>>> On Nov 7, 10:37 pm, "Steve" <no....@example.com> wrote:
>>>>>>> "Darko" <darko.maksimo...@gmail.com> wrote in message
>>>>>>>
>>>>>>> news:1194463439.305946.20240@z9g2000hsf.googlegroups.com...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Nov 7, 6:19 pm, "Steve" <no....@example.com> wrote:
>>>>>>>>> well !!! lo-and-behold!!! when you get your error message back
>>>>>>>>> THIS time,
>>>>>>>>> you actually get a line number OTHER THAN 1 !!! now THAT would be
>>>>>>>>> helpful!
>>>>>>>>> imagine too, that you echo this out to the browser, copy it, and
>>>>>>>>> paste it
>>>>>>>>> directly into your mysql query browser...then execute it. even
>>>>>>>>> before
>>>>>>>>> then,
>>>>>>>>> you might have discovered (since you can now READ IT) that there
>>>>>>>>> is
>>>>>>>>> something wrong in the data you're inserting.
>>>>>>>> Having yelled that out, haven't you ever noticed that mysql (and so
>>>>>>>> do
>>>>>>>> other
>>>>>>>> sql servers) specify precisely where the problem is - this time it
>>>>>>>> said:
>>>>>>>>> near 'from, size, format, cat, host ...
>>>>>>> you obviously haven't written very long or complex queries. 'near'
>>>>>>> and ON
>>>>>>> LINE x are *worlds* apart, now aren't they.
>>>>>>>
>>>>>>>> ... so it was quite clear that it had had problem with "from".
>>>>>>> apparently not quite as clear to the op. :)
>>>>>>>
>>>>>>>> Considering php and
>>>>>>>> queries code readability you are, of course, right, since a
>>>>>>>> programmer
>>>>>>>> will much more
>>>>>>>> easily read the code formatted in the way you have, but considering
>>>>>>>> error information,
>>>>>>> you should ammend that...'considering the error information [IN THIS
>>>>>>> CASE]'.
>>>>>>>
>>>>>>> either way, it should be formatted as a rule...unless you're saying
>>>>>>> you can
>>>>>>> predict your errors, in which case you wouldn't make mistakes
>>>>>>> anyway.
>>>>>>>
>>>>>>>> sql servers are pretty precise about where the problem occurred,
>>>>>>>> code
>>>>>>>> being indented
>>>>>>>> or not.
>>>>>>> really? which ones? what is 'pretty' precise?
>>>>>>>
>>>>>>> the indenting is multipurpose. it is my experience that the top 4
>>>>>>> sql
>>>>>>> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in
>>>>>>> their
>>>>>>> error messages...but they all give line numbers!
>>>>>>>
>>>>>>>>> don't let me throw you on that one...bad data is NOT the problem
>>>>>>>>> here.
>>>>>>>>> there
>>>>>>>>> are things called RESERVED WORDS. one of those would be the word
>>>>>>>>> 'FROM'...as
>>>>>>>>> in "select * FROM". if you had correctly formatted your sql
>>>>>>>>> statement,
>>>>>>>>> the
>>>>>>>>> line number in error would have been line 6...a much better clue.
>>>>>>>> As for rude yelling about making mistakes with reserved words, that
>>>>>>>> is
>>>>>>>> something that happens
>>>>>>>> to many people, even experienced, from time to time, so no need to
>>>>>>>> get
>>>>>>>> upset about it.
>>>>>>> rude? lol.
>>>>>>>
>>>>>>> you even infer rudeness about the mistake itself. no, i capitalized
>>>>>>> FROM so
>>>>>>> that it stood out. if that hurt your ears, then you won't hear me
>>>>>>> laughing
>>>>>>> right now. my intention throughout the thread here has been to make
>>>>>>> a point
>>>>>>> about formatting. did you not notice that even though i told him
>>>>>>> what the
>>>>>>> problem was, i did not tell him how to fix it? hmmmm...must not have
>>>>>>> been
>>>>>>> the goal of my post. seems you've missed that point.
>>>>>>>
>>>>>>>> I once
>>>>>>>> named two variables in C like "od" and "do", and couldn't find out
>>>>>>>> what was wrong with it until
>>>>>>>> I realised it was the "do" keyword.
>>>>>>> christ almighty! i suppose you proliferate the use of variables like
>>>>>>> $tmp
>>>>>>> too. what a goof! 'do'? for the love of god, almost *every* language
>>>>>>> has a
>>>>>>> *do* loop construct. so, when you said, 'even experienced' above,
>>>>>>> you were
>>>>>>> not associating yourself among those. :)
>>>>>>>
>>>>>>>> Finally, it is not "reserved" word in any sql, as you can indeed
>>>>>>>> name
>>>>>>>> any field "from", as long
>>>>>>>> as you make the parser know it. For an example, this is totally
>>>>>>>> legal:
>>>>>>>> select name, img, descr, "from", size, format from table;
>>>>>>> why yes. now why would i NOT explain that to the op? must not have
>>>>>>> been the
>>>>>>> purpose of my post. what's more, i'd be encouraging BAD behavior. if
>>>>>>> you
>>>>>>> think that's just my ho, why don't you prepose that question in a db
>>>>>>> forum...bring your asbestos umbrella, cuz it'll rain fire from the
>>>>>>> first
>>>>>>> response to the last. dba's are kinda picky that way.
>>>>>>>
>>>>>>>> just as long as you keep the double quotes around key words.
>>>>>>> ahhhh...you assume too much. oracle will fart on your double quotes.
>>>>>>> it
>>>>>>> likes either single tics or single back tics (`). again, you just
>>>>>>> killed a
>>>>>>> great chance for scalability. you should be able to take your code
>>>>>>> base and
>>>>>>> plop it down in front of any db and nothing breaks. you've forced
>>>>>>> yourself
>>>>>>> to reprogram when switching from one db to another...which is the
>>>>>>> shits when
>>>>>>> you're prototyping on your local pc using mysql and pushing code to
>>>>>>> production where teradata is the db being used.
>>>>>>>
>>>>>>> wanna keep going, darko?
>>>>>> Yes, please.
>>>>>>
>>>>>> It wasn't my intention to encourage Einstein30000 to use such field
>>>>>> names as "from" or "select",
>>>>>> the idea was only that such errors happen even to experienced
>>>>>> programmers, not indicating whether
>>>>>> I consider myself one or not - it's pretty relative thing, as you
>>>>>> know.
>>>>>>
>>>>>> As for "od" and "do", you should first know that I am a Serb, and
>>>>>> that
>>>>>> in Serbian language "od" means "from",
>>>>>> and "do" means "to", so "od 1 do 10" means "from 1 to 10". Thus, once
>>>>>> in a simple C program I needed such "from" and
>>>>>> "to" helper variables, and I named them "od" and "do". It would have
>>>>>> been much easier to avoid if I was writing in
>>>>>> English, which I usually do when making non-test programs, since then
>>>>>> it would be easier to "hear" it as the English
>>>>>> do. But, being switched to Serbian in my mind, I didn't see any
>>>>>> danger
>>>>>> coming of it, and the
>>>>>> compiler was pretty vague about the error, as you know it can be, and
>>>>>> I hardly recognized it. This is,
>>>>>> if you'd really like to know.
>>>>>>
>>>>>> As for yelling, your uppercasing "FROM" explanation doesn't mention
>>>>>> the "your sql statement is F.U.C.K.E.D", "well !!! lo-and-behold!!!",
>>>>>> "a line number OTHER THAN 1 !!! now THAT would be helpful! ", "since
>>>>>> you can now READ IT", "bad data is NOT the problem here. there are
>>>>>> things called RESERVED WORDS. " statements, which I normally
>>>>>> considered yelling. It's just not polite to address people like that,
>>>>>> especially ones that came for advice and help.
>>>>>>
>>>>>> Regards,
>>>>>> Darko
>>>>>>
>>>>> I'm with darko here. It took me about 5 seconds flat to realise what
>>>>> was wrong.
>>>>>
>>>>>
>>>>>
>>>>> No need to blow it across 15 lines.
>>>>>
>>>>> Unless you are the sort person who can't count beyond ten without
>>>>> taking their socks off.
>>>>>
>>>>>
>>>>> Mysql barfs where its parser gets confused..that was at the word
>>>>> 'from' Simple.
>>>> right. and no one is arguing the simple nature of identifying the
>>>> problem here. however, it becomes very difficult, not only to read, but
>>>> to maintain and debug sql statements that are not well
>>>> formatted...which helps more quickly identify the root cause when it is
>>>> less than obvious.
>>>>
>>>> i'm not for or against anyone. i'm for a systemic approach that covers
>>>> all the bases and is a best practice. that's all. it has little to do
>>>> with the actual problem faced here with reserved words.
>>> Sorry, Steve - I don't agree with your method of "properly formatting"
>>> the SQL. It takes way too much space on the page. It is not "correct"
>>> by virtually any programmer I know.
>>
>> too much space? is there a premium on space in your editor, jerry? would
>> you like me to post a query i have for running financial statistics here?
>> i would be more than willing to un-format it so just a single line in
>> order to save 'virtual' space on the 'virtual' page if you'd like. :)
>>
>
> Don't be an asshole again, Steve. My editor isn't limited, but my screen
> size is, and that wastes a lot of it.
again? when was i being an asshole at all, jerry? i was sarcastically making
a point. one of which is that your screen realestate is far less expensive
than spending the time it takes to debug non-functioning
queries...especially when the query is more complex that what it seems
you've written in the course of your experience. you'd probably start by
*formatting* said query so you could break it down and isolate the problem.
after all of that's done, you probably would spend a fraction of time fixing
the actual problem. if it is formatted to begin with, you are less likely to
introduce problems, more able to expand a query, and very quickly able to
fix whatever else may ail it.
if it's that big of a deal, buy an editor with code folding.
again, am i an asshole simply because i have been calmly disagreeing with
you?
>> as far as being 'correct by virtually any programmer i [you] know'...that
>> may be as 'virtual' as the space such a query takes up. as for what is
>> reported, documented, and written about code formatting - inclusive of
>> sql - i think you're outnumbered.
>>
>
> Yep, programmers with any sense don't do it that way. The do it similar
> to:
>
> SELECT a,b,c
> FROM x
> WHERE y='z';
>
> Or something similar. And in the almost 25 years I've been doing SQL, I
> can probably count on two hands the number of experienced programmers who
> write SQL as you did. And hundreds who do it the way I learned.
you know what? me too. however, those handful are the ones from whom i
learned the most. they showed me that consistency, simplicity, and
manageability are the keys to not only good code, but a successful career.
also, in addition to being an asshole for disagreeing with you, jerry, i'm
now a programmer without any sense...and for simply the same reason?! rof.
i'm chuckling even more now though. don't you notice a difference between
the example you gave:
select a, b, c
from x
where y='z'
and the real formatting issue being discussed here...in the genre of:
select a, b, c from x where y='z'
hmmmm...the former being formatted in some way, the latter, not at all. and
i'm senseless?
let's take that example though a bit further and say we're dealing with php
code. if a function has parameters a, b, and c. you probably write it and
call it thusly:
function foo($a, $b, $c)
{
return true;
}
i bet though, that when your parameter names are very long and numerous, you
either single line them or column-ize them, like this:
function foo(
$a ,
$b ,
$c ,
...
)
{
return true;
}
and i bet you do the same when defining arrays, right? ask yourself why.
probably because it is more legible and maintainable, right? if the only
time you do this is when the function's params are way in the right margin,
forcing you to scroll to see them all...essencially screen space, i think
i'll but a gut.
>> for the same reasons you should format sql, you format any other language
>> you write in. i'm sure you've written lots of scripts that are over
>> several hundred lines. why would you approach writing sql any differently
>> than other language? just curious jerry. if you have no other explanation
>> than what you've stated, you've hardly made a case...except a 'special
>> case' which is therefore, a logical fallacy.
>
> I never said you shouldn't format SQL. I said the way you did it is
> stupid.
wow! i should have gotten 'stupid' from "I don't agree with your method..."?
i'm really going to have to read your posts with a lot more inferencing than
is normally due any other human being. that is, unless you are saying it is
stupid now...as opposed to "i said...".
likewise, rather than bash the way i format sql, wouldn't it have been more
helpful to address the point of FORMATTING sql - which was my point to begin
with. further, providing an example of the way YOU format sql would have
expanded the topic for the op. hell, i may even side with YOUR version of
formatting sql v. the way I format mine. but, simply leaving it at 'your way
is stupid, you're an asshole and senseless for disagreeing with me' doesn't
really help anyone...or, your cause - which i have yet to figure out here
yet.
> But like anyone with no argument, you keep trying to put words into my
> mouth.
wow jerry, i've been stating MY case. i've not even addressed any of your
points. look at your ONE, SINGLE POST in this thread. what POINT (much less
points, plural) did you actually make? you said you disagree with me. that's
fine. i simply added more reasons for you/anyone to understand why i and
others do things the way we do.
so please, quote me and the words you are proposing that i'm putting in your
mouth.
i hope you are not projecting on me here from some other thread where some
other person has bashed you. as you know, i have no beef with you. and
throughout this thread in rebuttal with you and darko, i've been unusually
polite. hence my puzzlement of being called an asshole, senseless, and
stupid. how did i get your ire up so?
[Back to original message]
|