mySQL Problem

[Einstein30000]

Hi,

in one of my php-scripts is the following query (with an already open
db-connection):

$q = "INSERT INTO main (name, img, descr, from, size, format, cat,
host, link, date) VALUES ('$name', '$img', '$descr', '$user', '$size',
'$format', '$cat', '$host', '$link', '$date')" or die(mysql_error ());

And when the query gets executed i get back the following error:

You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near 'from, size, format, cat, host, link, date) VALUES ('bla', '-',
'keine', 'Holgi',' at line 1

Whats wrong here?!

cheers

[John Murtari]

Re: mySQL Problem

Einstein30000 <dominic_ernst@ web.dewrites:

in one of my php-scripts is the following query (with an already open
db-connection):
>
$q = "INSERT INTO main (name, img, descr, from, size, format, cat,
host, link, date) VALUES ('$name', '$img', '$descr', '$user', '$size',
'$format', '$cat', '$host', '$link', '$date')" or die(mysql_error ());
>
And when the query gets executed i get back the following error:
>
You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near 'from, size, format, cat, host, link, date) VALUES ('bla', '-',
'keine', 'Holgi',' at line 1
>

FROM is a reserved word, you have to be careful on the column
names -- that is most likely the problem.

--
John
_______________ _______________ _______________ _______________ _______
John Murtari Software Workshop Inc.
jmurtari@follow ing domain 315.635-1968(x-211) "TheBook.Co m" (TM)
http://thebook.com/

[Darko]

Re: mySQL Problem

On Nov 7, 6:19 pm, "Steve" <no....@example .comwrote:

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 ...

.... so it was quite clear that it had had problem with "from".
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,
sql servers are pretty precise about where the problem occurred, code
being indented
or not.

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. 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.
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;

just as long as you keep the double quotes around key words.

Cheers

[Steve]

Re: mySQL Problem


"Darko" <darko.maksimov ic@gmail.comwro te in message
news:1194463439 .305946.20240@z 9g2000hsf.googl egroups.com...

On Nov 7, 6:19 pm, "Steve" <no....@example .comwrote:

>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...'conside ring 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?

[Darko]

Re: mySQL Problem

On Nov 7, 10:37 pm, "Steve" <no....@example .comwrote:

"Darko" <darko.maksimo. ..@gmail.comwro te in message
>
news:1194463439 .305946.20240@z 9g2000hsf.googl egroups.com...
>
>
>

On Nov 7, 6:19 pm, "Steve" <no....@example .comwrote:

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...'conside ring 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

[The Natural Philosopher]

Re: mySQL Problem

Darko wrote:

On Nov 7, 10:37 pm, "Steve" <no....@example .comwrote:

>"Darko" <darko.maksimo. ..@gmail.comwro te in message
>>
>news:119446343 9.305946.20240@ z9g2000hsf.goog legroups.com...
>>
>>
>>

>>On Nov 7, 6:19 pm, "Steve" <no....@example .comwrote:
>>>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...'conside ring 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'...a s
>>>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...brin g 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.

[lawrence k]

Re: mySQL Problem

On Nov 7, 12:19 pm, "Steve" <no....@example .comwrote:

"Einstein30 000" <dominic_er...@ web.dewrote in message
>
news:1194453026 .587359.180320@ 19g2000hsx.goog legroups.com...
>
>
>

Hi,

>

in one of my php-scripts is the following query (with an already open
db-connection):

>

$q = "INSERT INTO main (name, img, descr, from, size, format, cat,
host, link, date) VALUES ('$name', '$img', '$descr', '$user', '$size',
'$format', '$cat', '$host', '$link', '$date')" or die(mysql_error ());

>

And when the query gets executed i get back the following error:

>

You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near 'from, size, format, cat, host, link, date) VALUES ('bla', '-',
'keine', 'Holgi',' at line 1

>

Whats wrong here?!

>
your sql statement is F.U.C.K.E.D !!! hmmmm...perhaps you'll now see the
value in FORMATTING your queries where a HUMAN BEING can read it. makes it
easier to debug. :)

Programmers will always disagree about how to style their code. Which
is better, camelCase or under_scored variable names? People get into
holy wars over this stuff. A great deal of energy is wasted on issues
that, in the end, are mere matters of taste.

[Steve]

Re: mySQL Problem


"Darko" <darko.maksimov ic@gmail.comwro te in message
news:1194479286 .933437.249950@ 22g2000hsm.goog legroups.com...

On Nov 7, 10:37 pm, "Steve" <no....@example .comwrote:

>"Darko" <darko.maksimo. ..@gmail.comwro te in message
>>
>news:119446343 9.305946.20240@ z9g2000hsf.goog legroups.com...
>>
>>
>>

On Nov 7, 6:19 pm, "Steve" <no....@example .comwrote:
>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...'conside ring 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...brin g 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.

understood.

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.

you're completely forgiven then. :)

btw, it's a good sign that i'd no idea that english wasn't your native
language. i wish my non-native languages were masked with such adeptness.
good on you.

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.

no, in those cases other than 'FROM', i was in fact, being 'emphatic'. as
for yelling? no, my intension was at most, sarcasm. i've seen too many
people and in too much code from all skill levels not consider formatting
*anything*. what's worse is that most of those use some kind of gui query
builder that allows them to click and drag queries together, then display
the resulting sql...just to copy and paste it into 'production' code as a
one line string. yes, i get emphatic...but hardly a semantic difference
between the two; yelling and emphasis.

cheers.

[Steve]

Re: mySQL Problem


"The Natural Philosopher" <a@b.cwrote in message
news:1194484441 .81272.6@demete r.uk.clara.net. ..

Darko wrote:

>On Nov 7, 10:37 pm, "Steve" <no....@example .comwrote:

>>"Darko" <darko.maksimo. ..@gmail.comwro te in message
>>>
>>news:11944634 39.305946.20240 @z9g2000hsf.goo glegroups.com.. .
>>>
>>>
>>>
>>>On Nov 7, 6:19 pm, "Steve" <no....@example .comwrote:
>>>>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. :)
>>>
>>>Considerin g 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...'conside ring 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...bri ng 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...whi ch 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.

[Steve]

Re: mySQL Problem


"lawrence k" <lkrubner@geoci ties.comwrote in message
news:1194496438 .926297.74650@o 38g2000hse.goog legroups.com...

On Nov 7, 12:19 pm, "Steve" <no....@example .comwrote:

>"Einstein30000 " <dominic_er...@ web.dewrote in message
>>
>news:119445302 6.587359.180320 @19g2000hsx.goo glegroups.com.. .
>>
>>
>>

Hi,

>>

in one of my php-scripts is the following query (with an already open
db-connection):

>>

$q = "INSERT INTO main (name, img, descr, from, size, format, cat,
host, link, date) VALUES ('$name', '$img', '$descr', '$user', '$size',
'$format', '$cat', '$host', '$link', '$date')" or die(mysql_error ());

>>

And when the query gets executed i get back the following error:

>>

You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near 'from, size, format, cat, host, link, date) VALUES ('bla', '-',
'keine', 'Holgi',' at line 1

>>

Whats wrong here?!

>>
>your sql statement is F.U.C.K.E.D !!! hmmmm...perhaps you'll now see the
>value in FORMATTING your queries where a HUMAN BEING can read it. makes
>it
>easier to debug. :)

>
>
Programmers will always disagree about how to style their code. Which
is better, camelCase or under_scored variable names? People get into
holy wars over this stuff. A great deal of energy is wasted on issues
that, in the end, are mere matters of taste.

that's bullshit. i don't care what people prefer when they decide to
formalize their style of programming. what i get incensed about is when no
measure of formality is considered good practice. as for 'mere matters of
taste', you simply missed the boat on the subject at hand...NO FORMATTING
vs. ANY formatting.

[AnrDaemon]

Re: mySQL Problem

Greetings, Steve.
In reply to Your message dated Wednesday, November 7, 2007, 20:19:23,

"Einstein30 000" <dominic_ernst@ web.dewrote in message
news:1194453026 .587359.180320@ 19g2000hsx.goog legroups.com...

>Hi,
>>
>in one of my php-scripts is the following query (with an already open
>db-connection):
>>
>$q = "INSERT INTO main (name, img, descr, from, size, format, cat,
>host, link, date) VALUES ('$name', '$img', '$descr', '$user', '$size',
>'$format', '$cat', '$host', '$link', '$date')" or die(mysql_error ());
>>
>And when the query gets executed i get back the following error:
>>
>You have an error in your SQL syntax; check the manual that
>corresponds to your MySQL server version for the right syntax to use
>near 'from, size, format, cat, host, link, date) VALUES ('bla', '-',
>'keine', 'Holgi',' at line 1
>>
>Whats wrong here?!

your sql statement is F.U.C.K.E.D !!!

Agree but not in the way You think about.

hmmmm...perhaps you'll now see the
value in FORMATTING your queries where a HUMAN BEING can read it. makes it
easier to debug. :)

Actually, problem is proper quoting, not the format or anything else.

$sql = "
INSERT INTO main
(
`name` ,
`img` ,
`descr` ,
`from` ,
`size` ,
`format` ,
`cat` ,
`host` ,
`link` ,
`date`
)

That way. All should work now.


--
Sincerely Yours, AnrDaemon <anrdaemon@free mail.ru>

[Jerry Stuckle]

Re: mySQL Problem

Steve wrote:

"The Natural Philosopher" <a@b.cwrote in message
news:1194484441 .81272.6@demete r.uk.clara.net. ..

>Darko wrote:

>>On Nov 7, 10:37 pm, "Steve" <no....@example .comwrote:
>>>"Darko" <darko.maksimo. ..@gmail.comwro te in message
>>>>
>>>news:1194463 439.305946.2024 0@z9g2000hsf.go oglegroups.com. ..
>>>>
>>>>
>>>>
>>>>On Nov 7, 6:19 pm, "Steve" <no....@example .comwrote:
>>>>>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
>>>>>somethin g 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. :)
>>>>
>>>>Consideri ng 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...'conside ring 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'...a s
>>>>>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...brin g 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...yo u 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...whi ch 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.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Jerry Stuckle]

Re: mySQL Problem

AnrDaemon wrote:

Greetings, Steve.
In reply to Your message dated Wednesday, November 7, 2007, 20:19:23,
>
>

>"Einstein30000 " <dominic_ernst@ web.dewrote in message
>news:119445302 6.587359.180320 @19g2000hsx.goo glegroups.com.. .

>>Hi,
>>>
>>in one of my php-scripts is the following query (with an already open
>>db-connection):
>>>
>>$q = "INSERT INTO main (name, img, descr, from, size, format, cat,
>>host, link, date) VALUES ('$name', '$img', '$descr', '$user', '$size',
>>'$format', '$cat', '$host', '$link', '$date')" or die(mysql_error ());
>>>
>>And when the query gets executed i get back the following error:
>>>
>>You have an error in your SQL syntax; check the manual that
>>corresponds to your MySQL server version for the right syntax to use
>>near 'from, size, format, cat, host, link, date) VALUES ('bla', '-',
>>'keine', 'Holgi',' at line 1
>>>
>>Whats wrong here?!

>

>your sql statement is F.U.C.K.E.D !!!

>
Agree but not in the way You think about.
>

>hmmmm...perhap s you'll now see the
>value in FORMATTING your queries where a HUMAN BEING can read it. makes it
>easier to debug. :)

>
Actually, problem is proper quoting, not the format or anything else.
>

>$sql = "
> INSERT INTO main
> (
> `name` ,
> `img` ,
> `descr` ,
> `from` ,
> `size` ,
> `format` ,
> `cat` ,
> `host` ,
> `link` ,
> `date`
> )

>
That way. All should work now.
>
>

No, the REAL solution is to not use reserved words as column names.
Then you don't need the quotes - which, BTW, are a MySQL extension to
the SQL standard and won't work on any other RDBMS I'm familiar with.

And it's better to ask SQL questions in a SQL newsgroup.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Darko]

Re: mySQL Problem

On Nov 8, 5:33 am, lawrence k <lkrub...@geoci ties.comwrote:

On Nov 7, 12:19 pm, "Steve" <no....@example .comwrote:
>
>
>

"Einstein30 000" <dominic_er...@ web.dewrote in message

>

news:1194453026 .587359.180320@ 19g2000hsx.goog legroups.com...

>

Hi,

>

in one of my php-scripts is the following query (with an already open
db-connection):

>

$q = "INSERT INTO main (name, img, descr, from, size, format, cat,
host, link, date) VALUES ('$name', '$img', '$descr', '$user', '$size',
'$format', '$cat', '$host', '$link', '$date')" or die(mysql_error ());

>

And when the query gets executed i get back the following error:

>

You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near 'from, size, format, cat, host, link, date) VALUES ('bla', '-',
'keine', 'Holgi',' at line 1

>

Whats wrong here?!

>

your sql statement is F.U.C.K.E.D !!! hmmmm...perhaps you'll now see the
value in FORMATTING your queries where a HUMAN BEING can read it. makes it
easier to debug. :)

>
Programmers will always disagree about how to style their code. Which
is better, camelCase or under_scored variable names? People get into
holy wars over this stuff. A great deal of energy is wasted on issues
that, in the end, are mere matters of taste.

I didn't disagree with Steve on formatting issue. I merely said that
it wasn't
crucial to see where the error was, and I also said that it isn't such
a big
deal if someone names a variable/column with a reserved word, since it
can happen
to anyone.

As for formatting, of course, I can't stand it when I see the lack of
it, and I always
correct it on the fly while reading a piece of code. As do most
programmers here,
I believe (I hope).

[Darko]

Re: mySQL Problem

On Nov 8, 5:43 am, "Steve" <no....@example .comwrote:

"Darko" <darko.maksimo. ..@gmail.comwro te in message
>
news:1194479286 .933437.249950@ 22g2000hsm.goog legroups.com...
>
>
>

On Nov 7, 10:37 pm, "Steve" <no....@example .comwrote:

"Darko" <darko.maksimo. ..@gmail.comwro te in message

>

>news:119446343 9.305946.20240@ z9g2000hsf.goog legroups.com...

>

On Nov 7, 6:19 pm, "Steve" <no....@example .comwrote:
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...'conside ring 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.

>
understood.
>

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.

>
you're completely forgiven then. :)
>
btw, it's a good sign that i'd no idea that english wasn't your native
language. i wish my non-native languages were masked with such adeptness.
good on you.

Thanks :) Concerning that, you should also know I don't live in
English-speaking
area and it's not my everyday language [just bragging].

>

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.

>
no, in those cases other than 'FROM', i was in fact, being 'emphatic'. as
for yelling? no, my intension was at most, sarcasm. i've seen too many
people and in too much code from all skill levels not consider formatting
*anything*. what's worse is that most of those use some kind of gui query
builder that allows them to click and drag queries together, then display
the resulting sql...just to copy and paste it into 'production' code as a
one line string. yes, i get emphatic...but hardly a semantic difference
between the two; yelling and emphasis.
>
cheers.

OK, sarcasm can definitely be forgiven more easily than yelling, and I
think
uppercasing is usually understood as yelling. Maybe italic would be
good for
sarcasm? If only we could have it here...