By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,485 Members | 1,061 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,485 IT Pros & Developers. It's quick & easy.

mySQL Problem

P: n/a
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

Nov 7 '07 #1
Share this Question
Share on Google+
30 Replies


P: n/a
Einstein30000 <do***********@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@following domain 315.635-1968(x-211) "TheBook.Com" (TM)
http://thebook.com/
Nov 7 '07 #2

P: n/a
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

Nov 7 '07 #3

P: n/a

"Darko" <da**************@gmail.comwrote in message
news:11*********************@z9g2000hsf.googlegrou ps.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...'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?
Nov 7 '07 #4

P: n/a
On Nov 7, 10:37 pm, "Steve" <no....@example.comwrote:
"Darko" <darko.maksimo...@gmail.comwrote in message

news:11*********************@z9g2000hsf.googlegrou ps.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...'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

Nov 7 '07 #5

P: n/a
Darko wrote:
On Nov 7, 10:37 pm, "Steve" <no....@example.comwrote:
>"Darko" <darko.maksimo...@gmail.comwrote in message

news:11*********************@z9g2000hsf.googlegro ups.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...'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.
Nov 8 '07 #6

P: n/a
On Nov 7, 12:19 pm, "Steve" <no....@example.comwrote:
"Einstein30000" <dominic_er...@web.dewrote in message

news:11**********************@19g2000hsx.googlegro ups.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.
Nov 8 '07 #7

P: n/a

"Darko" <da**************@gmail.comwrote in message
news:11**********************@22g2000hsm.googlegro ups.com...
On Nov 7, 10:37 pm, "Steve" <no....@example.comwrote:
>"Darko" <darko.maksimo...@gmail.comwrote in message

news:11*********************@z9g2000hsf.googlegro ups.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...'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.
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.
Nov 8 '07 #8

P: n/a

"The Natural Philosopher" <a@b.cwrote in message
news:11****************@demeter.uk.clara.net...
Darko wrote:
>On Nov 7, 10:37 pm, "Steve" <no....@example.comwrote:
>>"Darko" <darko.maksimo...@gmail.comwrote in message

news:11*********************@z9g2000hsf.googlegr oups.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...'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.
Nov 8 '07 #9

P: n/a

"lawrence k" <lk******@geocities.comwrote in message
news:11*********************@o38g2000hse.googlegro ups.com...
On Nov 7, 12:19 pm, "Steve" <no....@example.comwrote:
>"Einstein30000" <dominic_er...@web.dewrote in message

news:11**********************@19g2000hsx.googlegr oups.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.
Nov 8 '07 #10

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

"Einstein30000" <do***********@web.dewrote in message
news:11**********************@19g2000hsx.googlegro ups.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 <an*******@freemail.ru>

Nov 8 '07 #11

P: n/a
Steve wrote:
"The Natural Philosopher" <a@b.cwrote in message
news:11****************@demeter.uk.clara.net...
>Darko wrote:
>>On Nov 7, 10:37 pm, "Steve" <no....@example.comwrote:
"Darko" <darko.maksimo...@gmail.comwrote in message

news:11*********************@z9g2000hsf.googleg roups.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...'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.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Nov 8 '07 #12

P: n/a
AnrDaemon wrote:
Greetings, Steve.
In reply to Your message dated Wednesday, November 7, 2007, 20:19:23,

>"Einstein30000" <do***********@web.dewrote in message
news:11**********************@19g2000hsx.googlegr oups.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.

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.
js*******@attglobal.net
==================

Nov 8 '07 #13

P: n/a
On Nov 8, 5:33 am, lawrence k <lkrub...@geocities.comwrote:
On Nov 7, 12:19 pm, "Steve" <no....@example.comwrote:
"Einstein30000" <dominic_er...@web.dewrote in message
news:11**********************@19g2000hsx.googlegro ups.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).

Nov 8 '07 #14

P: n/a
On Nov 8, 5:43 am, "Steve" <no....@example.comwrote:
"Darko" <darko.maksimo...@gmail.comwrote in message

news:11**********************@22g2000hsm.googlegro ups.com...
On Nov 7, 10:37 pm, "Steve" <no....@example.comwrote:
"Darko" <darko.maksimo...@gmail.comwrote in message
>news:11*********************@z9g2000hsf.googlegro ups.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...'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.

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

Nov 8 '07 #15

P: n/a
On Nov 8, 2:28 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
Steve wrote:
"The Natural Philosopher" <a...@b.cwrote in message
news:11****************@demeter.uk.clara.net...
Darko wrote:
On Nov 7, 10:37 pm, "Steve" <no....@example.comwrote:
"Darko" <darko.maksimo...@gmail.comwrote in message
>>>news:11*********************@z9g2000hsf.googleg roups.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...'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.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
I must agree with you on this one. I do format my queries in code, but
it looks something like this:

$query = sprintf(
"INSERT INTO " .
"main " .
"(name, img, descr, from, size, format, cat, host, link, date)
" .
"VALUES " .
"('%s', '%s', '%s', '%s', %f, '%s', '%s', '%s', '%s', '%s')",
mysql_real_escape_string( $name ),
...
);

$queryResult = @mysql_query( $query );
if ( $queryResult === FALSE ) {
throw new Exception( "..." );
....

....with exception, of course, that I would try to avoid the "from"
sort of variable
names. This is pretty shorter, and still good enough to understand (at
least for me)

Darko

Nov 8 '07 #16

P: n/a

"Darko" <da**************@gmail.comwrote in message
news:11**********************@k35g2000prh.googlegr oups.com...
On Nov 8, 5:43 am, "Steve" <no....@example.comwrote:
>"Darko" <darko.maksimo...@gmail.comwrote in message

news:11**********************@22g2000hsm.googlegr oups.com...
On Nov 7, 10:37 pm, "Steve" <no....@example.comwrote:
"Darko" <darko.maksimo...@gmail.comwrote in message
>>news:11*********************@z9g2000hsf.googlegr oups.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...'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.

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].
wish i could say the same. i used to speak spanish fluently by age 10. i
spoke it every day with my friends and when i'd go over to their house. now
that i'm out of school and work all the time with english speakers, i can
only half-way make out a discussion in spanish...although i've been asked to
'interpret' a couple of times for one of our sister companies based in
mexico.

don't even get me started on my japanese. :)
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...
i'll concede your point. less casing, more italics/asterisks/etc. :)

cheers
Nov 8 '07 #17

P: n/a
Einstein30000 wrote:
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
Bypassing the constant back and forths herein this thread, let me say what I
do.

I format my query (as an example):

$q = "INSERT INTO Client (name, org_type, street1, street2, city, state, " .
"zip, mainPhone, county) " .
"VALUES (" .
GetSQLValueString($organization, "text") . ", " .
GetSQLValueString($orgTypeList, "text") . ", " .
GetSQLValueString($street1, "text") . ", " .
GetSQLValueString($street2, "text") . ", " .
GetSQLValueString($city, "text") . ", " .
GetSQLValueString(strtoupper($state), "text") . ", " .
GetSQLValueString($zip, "text") . ", " .
GetSQLValueString($mainPhone, "text") . ", " .
GetSQLValueString($county, "text") . ")";

(The GetSQLValueString is a function that does all the proper preparation
for the field.)

NOW, when I get an error, I also get a line number. If I still have
trouble, I do an echo $q, and I copy the resulting query. (Often, I see the
problem right here, though). I then go to the phpmyadmin and paste in that
query. I use the MySQL error tools to help find the problem. It is quicker
this way as I can adjust parameters there to get it to work. I then make
those mods required in my code to generate the correct query. In your case
it would have flagged the problem right away.

Shelly


Nov 8 '07 #18

P: n/a
Steve wrote:
- snip -

I must agree with you on this one. I do format my queries in code, but
it looks something like this:

$query = sprintf(
"INSERT INTO " .
"main " .
"(name, img, descr, from, size, format, cat, host, link, date)
" .
"VALUES " .
"('%s', '%s', '%s', '%s', %f, '%s', '%s', '%s', '%s', '%s')",
mysql_real_escape_string( $name ),
...
);

$queryResult = @mysql_query( $query );
if ( $queryResult === FALSE ) {
throw new Exception( "..." );
...

...with exception, of course, that I would try to avoid the "from"
sort of variable
names. This is pretty shorter, and still good enough to understand (at
least for me)

right. it is short. but, why apply formatting in one instance and not
another? the inconsistency kills me. further, should your now simple query
become not so simple in the future, you'll have to re-write. and second, if
your columns name are numerous and long, how would you visually be able to
say this value is being inserted into this column?

ot for a second... why not:

function prepare(&$value)
{
return $value = "'" . mysql_real_escape_string($value) . "'";
}

$values = array(
$value1 ,
$value2 ,
...
);
array_walk('prepare', $values);
$sql = "
insert into sample
(
column1 ,
column2 ,
)
values
(
" . implode(", \r\n", $values) . "
)
";
echo '<pre>' . print_r($sql, true) . '</pre>';

if you utilize array_walk, you've got only one spot to maintain the
preparation of your values. further, if you make the function NOT utilze
mysql_* functions but still provide the same functionality, you can move
from db to db without ever having to do a re-write.
Of course, I utilize a DBFactory that produces an implementation of
DBConnection interface (which is either PGConnection (for Postgres) or
MySQLConnection (for MySQL). That way they have a common interface,
addSlashes() being amongst them.
further, notice that
even when using implode(), i can still get a nicely formatted query to the
browser should i need to debug it...AND (sorry, *and*)
Don't worry :)
i can easily,
visually tell what value goes with what column. just a thought.
Yes, of course, you tend to simplify debugging queries to the point
where majority of us don't.
This is probably because, me personally, I don't like multi hundred or
multi thousand lines
long files because I get confused in them. And I still get quite along
with queries formatted
the way described above.
>
ok, back on topic. can you tell me what the aim of this query is?
No, I can't :)

Cheers

Nov 8 '07 #19

P: n/a

"Darko" <da**************@gmail.comwrote in message
news:11*********************@k35g2000prh.googlegro ups.com...
Steve wrote:
- snip -

I must agree with you on this one. I do format my queries in code, but
it looks something like this:

$query = sprintf(
"INSERT INTO " .
"main " .
"(name, img, descr, from, size, format, cat, host, link, date)
" .
"VALUES " .
"('%s', '%s', '%s', '%s', %f, '%s', '%s', '%s', '%s', '%s')",
mysql_real_escape_string( $name ),
...
);

$queryResult = @mysql_query( $query );
if ( $queryResult === FALSE ) {
throw new Exception( "..." );
...

...with exception, of course, that I would try to avoid the "from"
sort of variable
names. This is pretty shorter, and still good enough to understand (at
least for me)

right. it is short. but, why apply formatting in one instance and not
another? the inconsistency kills me. further, should your now simple
query
become not so simple in the future, you'll have to re-write. and second,
if
your columns name are numerous and long, how would you visually be able
to
say this value is being inserted into this column?

ot for a second... why not:

function prepare(&$value)
{
return $value = "'" . mysql_real_escape_string($value) . "'";
}

$values = array(
$value1 ,
$value2 ,
...
);
array_walk('prepare', $values);
$sql = "
insert into sample
(
column1 ,
column2 ,
)
values
(
" . implode(", \r\n", $values) . "
)
";
echo '<pre>' . print_r($sql, true) . '</pre>';

if you utilize array_walk, you've got only one spot to maintain the
preparation of your values. further, if you make the function NOT utilze
mysql_* functions but still provide the same functionality, you can move
from db to db without ever having to do a re-write.

Of course, I utilize a DBFactory that produces an implementation of
DBConnection interface (which is either PGConnection (for Postgres) or
MySQLConnection (for MySQL). That way they have a common interface,
addSlashes() being amongst them.
>further, notice that
even when using implode(), i can still get a nicely formatted query to
the
browser should i need to debug it...AND (sorry, *and*)

Don't worry :)
>i can easily,
visually tell what value goes with what column. just a thought.

Yes, of course, you tend to simplify debugging queries to the point
where majority of us don't.
i spend the majority of my programming efforts with inventory, billing, and
invoicing. my queries tend to be large and could get complex quickly. i
build them up in pieces so i can test every portion. when each works, i pull
them all together. the formatting is a life saver in making sure everything
works...and when it doesn't, i can copy just the ill-effected portion out to
test it.

while i don't dogmatically follow a standard of formatting, i am consistent.
i stray little...even when it's an insert statement as we've seen here. to
me, the most important portion of a script that deals with a db is the
queries it employs. when i see people wanting to save virtual screen space
by improperly, or not at all, formatting...it just indicates to me that the
query itself was not given it's due merit. that means that a lot of things
surrounding the data processing could have been overlooked. that's just me.
not everyone is accounting for revenues that could be drastically
over/understated if a query is not written correctly (formatting aside).
This is probably because, me personally, I don't like multi hundred or
multi thousand lines
long files because I get confused in them.
i have functions that isolate much of the data summarization that i need.
that's how i separate out the bigger queries. i'll call on the summarized
data with quite simple and manageable sql statements. and those don't span
more than 10 to 20 lines even with my affinity to format the way i do.
And I still get quite along
with queries formatted
the way described above.
as do most of us. if there is *some* formatting, that's great. it was
obvious, given the error message pointing to line 1 even though the sql
wrapped in the post, that the op just slopped the mess together...and
wonders why it won't work. of course his problem was with reserved words,
but spotting other errors may not be so easily overcome next time.
>>
ok, back on topic. can you tell me what the aim of this query is?

No, I can't :)
it breaks out totals for different charges (dollars and hours) based on a
data segment...say, who the estimator was, or what insurance company was
used...basically, a totalling for any field in either of the two tables
(estimates/repairs).

again, how ever you or anyone else formats it, i don't care. the point is
*to* format.

cheers.
Nov 8 '07 #20

P: n/a
Steve wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
<crap>

You aren't even reading what I'm saying. And you should see who started
the insults.

Sorry, Steve. You're not going to get any rise out of me for your crap.
This is my last post to you on the subject.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Nov 8 '07 #21

P: n/a
On Nov 8, 11:20 pm, "Steve" <no....@example.comwrote:
"Jerry Stuckle" <jstuck...@attglobal.netwrote in message

news:je******************************@comcast.com. ..
Steve wrote:
"Jerry Stuckle" <jstuck...@attglobal.netwrote in message
<crap>

crap? i directly explained how you are not getting what my point was, and
how the debate you are wanting is not germain to my original point. how is
that crap?
You aren't even reading what I'm saying.

really? you are talking about how my style of formatting sql is poor. i, and
the rest of us, are talking about the fact that formatting should be applied
to sql. i think that shows at least *one* of us has been paying attention.
And you should see who started the insults.

really? make a bet with you. go to the earliest thread that you can and
quote the insult i flung at you. i'll do the same. the one who has the
earliest date stamp wins, ok?

let's get started...

Message-ID: <8Y******************************@comcast.com>

jerry: "Don't be an asshole again, Steve"
jerry: "Yep, programmers with any sense don't do it that way."
jerry: "I said the way you did it is stupid."
jerry: "But like anyone with no argument, you keep
trying to put words into my mouth."

wow, i almost quoted the ENTIRE response dated: 2007-11-08 11:47 AM !!!

ok, now it's your turn. :)
Sorry, Steve. You're not going to get any rise out of me for your crap.

again, crap? please explain.
This is my last post to you on the subject.

probably because i gave you direct points for you to address and you can't
seem to or won't. a proper EOT is when one is either proven wrong, agree to
disagree, or cannot seem to establish the topic being had. i still don't
think you realize that it is the latter in this case.

at least support your *evidence* that I STARTED the insults to you. that's
just an out-and-out L.I.E.. the last post i made did get stern, but
certainly didn't contain ad-hom's...just restrained frustration.
You should both know, based on your seemingly vast work experience,
the general
rule of aggresive argument - no one started it first, everyone was
just provoked.
(for it sounds good, I must remark it isn't really some official rule,
but something
I made out in the moment :)

What's worse (or better), everyone thinks they're right, so usually no
lies are
included (except maybe for tiny ones ;)

Cheers

Nov 9 '07 #22

P: n/a

"Darko" <da**************@gmail.comwrote in message
news:11**********************@q5g2000prf.googlegro ups.com...
On Nov 8, 11:20 pm, "Steve" <no....@example.comwrote:
>"Jerry Stuckle" <jstuck...@attglobal.netwrote in message

news:je******************************@comcast.com ...
Steve wrote:
"Jerry Stuckle" <jstuck...@attglobal.netwrote in message
<crap>

crap? i directly explained how you are not getting what my point was, and
how the debate you are wanting is not germain to my original point. how
is
that crap?
You aren't even reading what I'm saying.

really? you are talking about how my style of formatting sql is poor. i,
and
the rest of us, are talking about the fact that formatting should be
applied
to sql. i think that shows at least *one* of us has been paying
attention.
And you should see who started the insults.

really? make a bet with you. go to the earliest thread that you can and
quote the insult i flung at you. i'll do the same. the one who has the
earliest date stamp wins, ok?

let's get started...

Message-ID: <8Y******************************@comcast.com>

jerry: "Don't be an asshole again, Steve"
jerry: "Yep, programmers with any sense don't do it that way."
jerry: "I said the way you did it is stupid."
jerry: "But like anyone with no argument, you keep
trying to put words into my mouth."

wow, i almost quoted the ENTIRE response dated: 2007-11-08 11:47 AM !!!

ok, now it's your turn. :)
Sorry, Steve. You're not going to get any rise out of me for your
crap.

again, crap? please explain.
This is my last post to you on the subject.

probably because i gave you direct points for you to address and you
can't
seem to or won't. a proper EOT is when one is either proven wrong, agree
to
disagree, or cannot seem to establish the topic being had. i still don't
think you realize that it is the latter in this case.

at least support your *evidence* that I STARTED the insults to you.
that's
just an out-and-out L.I.E.. the last post i made did get stern, but
certainly didn't contain ad-hom's...just restrained frustration.

You should both know, based on your seemingly vast work experience,
the general
rule of aggresive argument - no one started it first, everyone was
just provoked.
(for it sounds good, I must remark it isn't really some official rule,
but something
I made out in the moment :)

What's worse (or better), everyone thinks they're right, so usually no
lies are
included (except maybe for tiny ones ;)
lol. probably very true.

well, someone usually claims the other guy started it...i happen to be the
other guy and am simply challenging jerry to show that his claim was
correct. in this case, either he forgot or is creating a lie that i don't
feel is tiny enough to ignore. :)

i also don't mind being wrong. i've been there and will be again.
criticized? don't mind that either. jerry and i seem to go back and forth
sometimes because he tends to tangent from the point i am trying make. i
should learn by now, since i can never get him to come to topic or ever
directly counter. and, he usually ends the conversation just as he did here.
i get the impression that he skips most of people's posted content the more
of it there is or the harder he finds it to counter. while most of the time
he's right on a lot of things, you can not get him to think that either he
is wrong or hasn't understood he's arguing against things that were never
points of contention in the first place.

oh well.

later.
Nov 9 '07 #23

P: n/a
On Nov 8, 4:35 pm, "Steve" <no....@example.comwrote:
"Jerry Stuckle" <jstuck...@attglobal.netwrote in message

news:I8******************************@comcast.com. ..
But this is simple compared to many of the queries I've written in the
past. Try recursive queries in DB2 or Oracle, for instance. Some of them
get very long and very complicated. But I doubt you are even aware of
what a recursive query is.

here we go again, jerry! can you cut down on the overassumptive insults? i'd
stack my 25 years of programming experience against yours any day of the
week. yes, i know what recursion is an any context - even this one where you
continually fall back into the same pattern of insult after insult. most
recursive functions have a drop-out condition so it's not an endless loop.
what's yours?!

Steve, what the hell is wrong with you? I'm stunned at your lack of
self-awareness.

Nov 9 '07 #24

P: n/a

"lawrence k" <lk******@geocities.comwrote in message
news:11**********************@t8g2000prg.googlegro ups.com...
On Nov 8, 4:35 pm, "Steve" <no....@example.comwrote:
>"Jerry Stuckle" <jstuck...@attglobal.netwrote in message

news:I8******************************@comcast.com ...
But this is simple compared to many of the queries I've written in the
past. Try recursive queries in DB2 or Oracle, for instance. Some of
them
get very long and very complicated. But I doubt you are even aware of
what a recursive query is.

here we go again, jerry! can you cut down on the overassumptive insults?
i'd
stack my 25 years of programming experience against yours any day of the
week. yes, i know what recursion is an any context - even this one where
you
continually fall back into the same pattern of insult after insult. most
recursive functions have a drop-out condition so it's not an endless
loop.
what's yours?!


Steve, what the hell is wrong with you? I'm stunned at your lack of
self-awareness.
clarify, then perhaps we can discuss. you saying pot/kettle?
Nov 9 '07 #25

P: n/a
Greetings, Jerry Stuckle.
In reply to Your message dated Thursday, November 8, 2007, 16:31:15,
AnrDaemon wrote:
>Greetings, Steve.
In reply to Your message dated Wednesday, November 7, 2007, 20:19:23,

>>"Einstein30000" <do***********@web.dewrote in message
news:11**********************@19g2000hsx.googleg roups.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.

No, the REAL solution is to not use reserved words as column names.
Why if it's expected name for a column?
As far as field names is a strings, You can use any given name, even in Your
local encoding, and You can use spaces too.
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.
MS SQL Server use square brackets in the same way.
And I have no doubt that other server have identical solution for field
names.
I think You are wrong and lack of proper quotation in field names isan
extension, not the quotation.
And it's better to ask SQL questions in a SQL newsgroup.
/agree
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

Nov 9 '07 #26

P: n/a
AnrDaemon wrote:
Greetings, Jerry Stuckle.
In reply to Your message dated Thursday, November 8, 2007, 16:31:15,
>AnrDaemon wrote:
>>Greetings, Steve.
In reply to Your message dated Wednesday, November 7, 2007, 20:19:23,
"Einstein30000" <do***********@web.dewrote in message
news:11**********************@19g2000hsx.google groups.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.

>No, the REAL solution is to not use reserved words as column names.

Why if it's expected name for a column?
As far as field names is a strings, You can use any given name, even in Your
local encoding, and You can use spaces too.
Because FROM is a reserved word. Additionally, spaces are not
legitimate in column names (SQL databases do not have fields).

Learn the SQL specs. Then start MySQL in STRICT mode and watch it fail.
>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.

MS SQL Server use square brackets in the same way.
And I have no doubt that other server have identical solution for field
names.
I think You are wrong and lack of proper quotation in field names isan
extension, not the quotation.
There is NOTHING in the SQL specs which allows for such quoting. You
really need to get a copy and read it before making such statements. I
have.

And it's why SQL Server uses square brackets and MySQL uses back
tickies. There is no standard.
>And it's better to ask SQL questions in a SQL newsgroup.

/agree

And they will tell you exactly the same thing.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Nov 9 '07 #27

P: n/a
Greetings, Jerry Stuckle.
In reply to Your message dated Sunday, November 11, 2007, 17:05:47,
Why complicate things by putting SQL statements in a different file
where you can't see them?
It may be not that clear for You, but I actually support one project
runned on 2 different databases at the same time. (MySQL and MS SQL server)
And that schema was found better in all cases.
And why go to all that hassle when you can
use ANSI-compliant SQL and have it work on virtually every database
(except MS Access)? Complicates things unnecessarily, IMHO.
Well, can You translate cross-databse reference like [db1].[dbo].[table1] ?
There has been nothing in this thread which is non-ANSWI SQL - except
for the use of a reserved word in a column name.
I know.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

Nov 11 '07 #28

P: n/a
AnrDaemon wrote:
Greetings, Jerry Stuckle.
In reply to Your message dated Sunday, November 11, 2007, 17:05:47,
>Why complicate things by putting SQL statements in a different file
where you can't see them?

It may be not that clear for You, but I actually support one project
runned on 2 different databases at the same time. (MySQL and MS SQL server)
And that schema was found better in all cases.
Nope, what a confusion. I can think of much easier ways of doing that.
Including using ANSI-standard SQL.
>And why go to all that hassle when you can
use ANSI-compliant SQL and have it work on virtually every database
(except MS Access)? Complicates things unnecessarily, IMHO.

Well, can You translate cross-databse reference like [db1].[dbo].[table1] ?
When I see the possibility of multiple RDBMS's, I use standard SQL.
>There has been nothing in this thread which is non-ANSWI SQL - except
for the use of a reserved word in a column name.

I know.

But then I also have database access in classes. I have no SQL
statements or other database specific code in the web pages' code.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Nov 11 '07 #29

P: n/a

"AnrDaemon" <an*******@freemail.ruwrote in message
news:76**********************@freemail.ru...
Greetings, Jerry Stuckle.
In reply to Your message dated Sunday, November 11, 2007, 17:05:47,
>Why complicate things by putting SQL statements in a different file
where you can't see them?

It may be not that clear for You, but I actually support one project
runned on 2 different databases at the same time. (MySQL and MS SQL
server)
And that schema was found better in all cases.
>And why go to all that hassle when you can
use ANSI-compliant SQL and have it work on virtually every database
(except MS Access)? Complicates things unnecessarily, IMHO.

Well, can You translate cross-databse reference like [db1].[dbo].[table1]
?
actually, yes! even when working on the same db platform, it is a better
practice to create a view or other alias for the cross reference *in the
db*...not *in the code*. the db itself should handle that level of
minutia...after all, it's the *data layer*. code resides on top of that.

if you feel that your code should not only handle the processing of data but
the management of db relationships, particularly its sources, you will
forever entagle two layers that should be more losely coupled. the result
will be an explosion of re-writing any time you change your back-end
configuration.

by the same reasoning as having to specially denote column names that are
also reserved words, forcing in-line code to denote special
cross-referencing that are also db-specific and NOT ANSI compliant, you've
shot yourself in the foot.

luckily, this is a php context and changes to accomodate such 'mistakes' are
at least localized to source code distributed (usually) on one
computer...the web server. were this compiled sourced distributed as a
client application, you'd quickly see the wisdom in keeping the iso-seven
layers as seperated as possible.
Nov 12 '07 #30

P: n/a
Greetings, Gary L . Burnore.
In reply to Your message dated Monday, November 12, 2007, 02:09:58,
>>Why complicate things by putting SQL statements in a different file
where you can't see them?

It may be not that clear for You, but I actually support one project
runned on 2 different databases at the same time. (MySQL and MS SQL server)
And that schema was found better in all cases.
Better than what?
Better than include SQL code in PHP code.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

Nov 15 '07 #31

This discussion thread is closed

Replies have been disabled for this discussion.