mySQL Problem

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

Re: mySQL Problem

"Einstein30000" wrote in message
news:1194453026.587359.180320@19g2000hsx.googlegroups.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. :)

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

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.

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.

please put into use what has been well documented and implemented as 'best
practices', or, 'standards of practice'.

(what? so i have a pet peave about illegible code...bfd!)

Re: mySQL Problem

Einstein30000 writes:

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

Re: mySQL Problem

On Nov 7, 6:19 pm, "Steve" wrote:
> well !!! lo-and-behold!!! when you get your error message back THIS time,
> you actually get a line number OTHER THAN 1 !!! now THAT would be helpful!
> imagine too, that you echo this out to the browser, copy it, and paste it
> directly into your mysql query browser...then execute it. even before then,
> you might have discovered (since you can now READ IT) that there is
> something wrong in the data you're inserting.
>

Having yelled that out, haven't you ever noticed that mysql (and so do
other
sql servers) specify precisely where the problem is - this time it
said:

> near 'from, size, format, cat, host ...

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

Re: mySQL Problem

"Darko" wrote in message
news:1194463439.305946.20240@z9g2000hsf.googlegroups.com...
> On Nov 7, 6:19 pm, "Steve" wrote:
>> well !!! lo-and-behold!!! when you get your error message back THIS time,
>> you actually get a line number OTHER THAN 1 !!! now THAT would be
>> helpful!
>> imagine too, that you echo this out to the browser, copy it, and paste it
>> directly into your mysql query browser...then execute it. even before
>> then,
>> you might have discovered (since you can now READ IT) that there is
>> something wrong in the data you're inserting.
>>
>
> Having yelled that out, haven't you ever noticed that mysql (and so do
> other
> sql servers) specify precisely where the problem is - this time it
> said:
>
>> near 'from, size, format, cat, host ...

you obviously haven't written very long or complex queries. 'near' and ON
LINE x are *worlds* apart, now aren't they.

> ... so it was quite clear that it had had problem with "from".

apparently not quite as clear to the op. :)

> Considering php and
> queries code readability you are, of course, right, since a programmer
> will much more
> easily read the code formatted in the way you have, but considering
> error information,

you should ammend that...'considering the error information [IN THIS CASE]'.

either way, it should be formatted as a rule...unless you're saying you can
predict your errors, in which case you wouldn't make mistakes anyway.

> sql servers are pretty precise about where the problem occurred, code
> being indented
> or not.

really? which ones? what is 'pretty' precise?

the indenting is multipurpose. it is my experience that the top 4 sql
servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in their
error messages...but they all give line numbers!

>> don't let me throw you on that one...bad data is NOT the problem here.
>> there
>> are things called RESERVED WORDS. one of those would be the word
>> 'FROM'...as
>> in "select * FROM". if you had correctly formatted your sql statement,
>> the
>> line number in error would have been line 6...a much better clue.
>
> As for rude yelling about making mistakes with reserved words, that is
> something that happens
> to many people, even experienced, from time to time, so no need to get
> upset about it.

rude? lol.

you even infer rudeness about the mistake itself. no, i capitalized FROM so
that it stood out. if that hurt your ears, then you won't hear me laughing
right now. my intention throughout the thread here has been to make a point
about formatting. did you not notice that even though i told him what the
problem was, i did not tell him how to fix it? hmmmm...must not have been
the goal of my post. seems you've missed that point.

> I once
> named two variables in C like "od" and "do", and couldn't find out
> what was wrong with it until
> I realised it was the "do" keyword.

christ almighty! i suppose you proliferate the use of variables like $tmp
too. what a goof! 'do'? for the love of god, almost *every* language has a
*do* loop construct. so, when you said, 'even experienced' above, you were
not associating yourself among those. :)

> Finally, it is not "reserved" word in any sql, as you can indeed name
> any field "from", as long
> as you make the parser know it. For an example, this is totally legal:
>
> select name, img, descr, "from", size, format from table;

why yes. now why would i NOT explain that to the op? must not have been the
purpose of my post. what's more, i'd be encouraging BAD behavior. if you
think that's just my ho, why don't you prepose that question in a db
forum...bring your asbestos umbrella, cuz it'll rain fire from the first
response to the last. dba's are kinda picky that way.

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

ahhhh...you assume too much. oracle will fart on your double quotes. it
likes either single tics or single back tics (`). again, you just killed a
great chance for scalability. you should be able to take your code base and
plop it down in front of any db and nothing breaks. you've forced yourself
to reprogram when switching from one db to another...which is the shits when
you're prototyping on your local pc using mysql and pushing code to
production where teradata is the db being used.

wanna keep going, darko?

Re: mySQL Problem

On Nov 7, 10:37 pm, "Steve" wrote:
> "Darko" wrote in message
>
> news:1194463439.305946.20240@z9g2000hsf.googlegroups.com...
>
>
>
> > On Nov 7, 6:19 pm, "Steve" wrote:
> >> well !!! lo-and-behold!!! when you get your error message back THIS time,
> >> you actually get a line number OTHER THAN 1 !!! now THAT would be
> >> helpful!
> >> imagine too, that you echo this out to the browser, copy it, and paste it
> >> directly into your mysql query browser...then execute it. even before
> >> then,
> >> you might have discovered (since you can now READ IT) that there is
> >> something wrong in the data you're inserting.
>
> > Having yelled that out, haven't you ever noticed that mysql (and so do
> > other
> > sql servers) specify precisely where the problem is - this time it
> > said:
>
> >> near 'from, size, format, cat, host ...
>
> you obviously haven't written very long or complex queries. 'near' and ON
> LINE x are *worlds* apart, now aren't they.
>
> > ... so it was quite clear that it had had problem with "from".
>
> apparently not quite as clear to the op. :)
>
> > Considering php and
> > queries code readability you are, of course, right, since a programmer
> > will much more
> > easily read the code formatted in the way you have, but considering
> > error information,
>
> you should ammend that...'considering the error information [IN THIS CASE]'.
>
> either way, it should be formatted as a rule...unless you're saying you can
> predict your errors, in which case you wouldn't make mistakes anyway.
>
> > sql servers are pretty precise about where the problem occurred, code
> > being indented
> > or not.
>
> really? which ones? what is 'pretty' precise?
>
> the indenting is multipurpose. it is my experience that the top 4 sql
> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in their
> error messages...but they all give line numbers!
>
> >> don't let me throw you on that one...bad data is NOT the problem here.
> >> there
> >> are things called RESERVED WORDS. one of those would be the word
> >> 'FROM'...as
> >> in "select * FROM". if you had correctly formatted your sql statement,
> >> the
> >> line number in error would have been line 6...a much better clue.
>
> > As for rude yelling about making mistakes with reserved words, that is
> > something that happens
> > to many people, even experienced, from time to time, so no need to get
> > upset about it.
>
> rude? lol.
>
> you even infer rudeness about the mistake itself. no, i capitalized FROM so
> that it stood out. if that hurt your ears, then you won't hear me laughing
> right now. my intention throughout the thread here has been to make a point
> about formatting. did you not notice that even though i told him what the
> problem was, i did not tell him how to fix it? hmmmm...must not have been
> the goal of my post. seems you've missed that point.
>
> > I once
> > named two variables in C like "od" and "do", and couldn't find out
> > what was wrong with it until
> > I realised it was the "do" keyword.
>
> christ almighty! i suppose you proliferate the use of variables like $tmp
> too. what a goof! 'do'? for the love of god, almost *every* language has a
> *do* loop construct. so, when you said, 'even experienced' above, you were
> not associating yourself among those. :)
>
> > Finally, it is not "reserved" word in any sql, as you can indeed name
> > any field "from", as long
> > as you make the parser know it. For an example, this is totally legal:
>
> > select name, img, descr, "from", size, format from table;
>
> why yes. now why would i NOT explain that to the op? must not have been the
> purpose of my post. what's more, i'd be encouraging BAD behavior. if you
> think that's just my ho, why don't you prepose that question in a db
> forum...bring your asbestos umbrella, cuz it'll rain fire from the first
> response to the last. dba's are kinda picky that way.
>
> > just as long as you keep the double quotes around key words.
>
> ahhhh...you assume too much. oracle will fart on your double quotes. it
> likes either single tics or single back tics (`). again, you just killed a
> great chance for scalability. you should be able to take your code base and
> plop it down in front of any db and nothing breaks. you've forced yourself
> to reprogram when switching from one db to another...which is the shits when
> you're prototyping on your local pc using mysql and pushing code to
> production where teradata is the db being used.
>
> wanna keep going, darko?

Yes, please.

It wasn't my intention to encourage Einstein30000 to use such field
names as "from" or "select",
the idea was only that such errors happen even to experienced
programmers, not indicating whether
I consider myself one or not - it's pretty relative thing, as you
know.

As for "od" and "do", you should first know that I am a Serb, and that
in Serbian language "od" means "from",
and "do" means "to", so "od 1 do 10" means "from 1 to 10". Thus, once
in a simple C program I needed such "from" and
"to" helper variables, and I named them "od" and "do". It would have
been much easier to avoid if I was writing in
English, which I usually do when making non-test programs, since then
it would be easier to "hear" it as the English
do. But, being switched to Serbian in my mind, I didn't see any danger
coming of it, and the
compiler was pretty vague about the error, as you know it can be, and
I hardly recognized it. This is,
if you'd really like to know.

As for yelling, your uppercasing "FROM" explanation doesn't mention
the "your sql statement is F.U.C.K.E.D", "well !!! lo-and-behold!!!",
"a line number OTHER THAN 1 !!! now THAT would be helpful! ", "since
you can now READ IT", "bad data is NOT the problem here. there are
things called RESERVED WORDS. " statements, which I normally
considered yelling. It's just not polite to address people like that,
especially ones that came for advice and help.

Regards,
Darko

Re: mySQL Problem

Darko wrote:
> On Nov 7, 10:37 pm, "Steve" wrote:
>> "Darko" wrote in message
>>
>> news:1194463439.305946.20240@z9g2000hsf.googlegroups.com...
>>
>>
>>
>>> On Nov 7, 6:19 pm, "Steve" wrote:
>>>> well !!! lo-and-behold!!! when you get your error message back THIS time,
>>>> you actually get a line number OTHER THAN 1 !!! now THAT would be
>>>> helpful!
>>>> imagine too, that you echo this out to the browser, copy it, and paste it
>>>> directly into your mysql query browser...then execute it. even before
>>>> then,
>>>> you might have discovered (since you can now READ IT) that there is
>>>> something wrong in the data you're inserting.
>>> Having yelled that out, haven't you ever noticed that mysql (and so do
>>> other
>>> sql servers) specify precisely where the problem is - this time it
>>> said:
>>>> near 'from, size, format, cat, host ...
>> you obviously haven't written very long or complex queries. 'near' and ON
>> LINE x are *worlds* apart, now aren't they.
>>
>>> ... so it was quite clear that it had had problem with "from".
>> apparently not quite as clear to the op. :)
>>
>>> Considering php and
>>> queries code readability you are, of course, right, since a programmer
>>> will much more
>>> easily read the code formatted in the way you have, but considering
>>> error information,
>> you should ammend that...'considering the error information [IN THIS CASE]'.
>>
>> either way, it should be formatted as a rule...unless you're saying you can
>> predict your errors, in which case you wouldn't make mistakes anyway.
>>
>>> sql servers are pretty precise about where the problem occurred, code
>>> being indented
>>> or not.
>> really? which ones? what is 'pretty' precise?
>>
>> the indenting is multipurpose. it is my experience that the top 4 sql
>> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in their
>> error messages...but they all give line numbers!
>>
>>>> don't let me throw you on that one...bad data is NOT the problem here.
>>>> there
>>>> are things called RESERVED WORDS. one of those would be the word
>>>> 'FROM'...as
>>>> in "select * FROM". if you had correctly formatted your sql statement,
>>>> the
>>>> line number in error would have been line 6...a much better clue.
>>> As for rude yelling about making mistakes with reserved words, that is
>>> something that happens
>>> to many people, even experienced, from time to time, so no need to get
>>> upset about it.
>> rude? lol.
>>
>> you even infer rudeness about the mistake itself. no, i capitalized FROM so
>> that it stood out. if that hurt your ears, then you won't hear me laughing
>> right now. my intention throughout the thread here has been to make a point
>> about formatting. did you not notice that even though i told him what the
>> problem was, i did not tell him how to fix it? hmmmm...must not have been
>> the goal of my post. seems you've missed that point.
>>
>>> I once
>>> named two variables in C like "od" and "do", and couldn't find out
>>> what was wrong with it until
>>> I realised it was the "do" keyword.
>> christ almighty! i suppose you proliferate the use of variables like $tmp
>> too. what a goof! 'do'? for the love of god, almost *every* language has a
>> *do* loop construct. so, when you said, 'even experienced' above, you were
>> not associating yourself among those. :)
>>
>>> Finally, it is not "reserved" word in any sql, as you can indeed name
>>> any field "from", as long
>>> as you make the parser know it. For an example, this is totally legal:
>>> select name, img, descr, "from", size, format from table;
>> why yes. now why would i NOT explain that to the op? must not have been the
>> purpose of my post. what's more, i'd be encouraging BAD behavior. if you
>> think that's just my ho, why don't you prepose that question in a db
>> forum...bring your asbestos umbrella, cuz it'll rain fire from the first
>> response to the last. dba's are kinda picky that way.
>>
>>> just as long as you keep the double quotes around key words.
>> ahhhh...you assume too much. oracle will fart on your double quotes. it
>> likes either single tics or single back tics (`). again, you just killed a
>> great chance for scalability. you should be able to take your code base and
>> plop it down in front of any db and nothing breaks. you've forced yourself
>> to reprogram when switching from one db to another...which is the shits when
>> you're prototyping on your local pc using mysql and pushing code to
>> production where teradata is the db being used.
>>
>> wanna keep going, darko?
>
> Yes, please.
>
> It wasn't my intention to encourage Einstein30000 to use such field
> names as "from" or "select",
> the idea was only that such errors happen even to experienced
> programmers, not indicating whether
> I consider myself one or not - it's pretty relative thing, as you
> know.
>
> As for "od" and "do", you should first know that I am a Serb, and that
> in Serbian language "od" means "from",
> and "do" means "to", so "od 1 do 10" means "from 1 to 10". Thus, once
> in a simple C program I needed such "from" and
> "to" helper variables, and I named them "od" and "do". It would have
> been much easier to avoid if I was writing in
> English, which I usually do when making non-test programs, since then
> it would be easier to "hear" it as the English
> do. But, being switched to Serbian in my mind, I didn't see any danger
> coming of it, and the
> compiler was pretty vague about the error, as you know it can be, and
> I hardly recognized it. This is,
> if you'd really like to know.
>
> As for yelling, your uppercasing "FROM" explanation doesn't mention
> the "your sql statement is F.U.C.K.E.D", "well !!! lo-and-behold!!!",
> "a line number OTHER THAN 1 !!! now THAT would be helpful! ", "since
> you can now READ IT", "bad data is NOT the problem here. there are
> things called RESERVED WORDS. " statements, which I normally
> considered yelling. It's just not polite to address people like that,
> especially ones that came for advice and help.
>
> Regards,
> Darko
>
I'm with darko here. It took me about 5 seconds flat to realise what was
wrong.



No need to blow it across 15 lines.

Unless you are the sort person who can't count beyond ten without taking
their socks off.


Mysql barfs where its parser gets confused..that was at the word 'from'
Simple.

Re: mySQL Problem

On Nov 7, 12:19 pm, "Steve" wrote:
> "Einstein30000" wrote in message
>
> news:1194453026.587359.180320@19g2000hsx.googlegroups.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.

Re: mySQL Problem

"Darko" wrote in message
news:1194479286.933437.249950@22g2000hsm.googlegroups.com...
> On Nov 7, 10:37 pm, "Steve" wrote:
>> "Darko" wrote in message
>>
>> news:1194463439.305946.20240@z9g2000hsf.googlegroups.com...
>>
>>
>>
>> > On Nov 7, 6:19 pm, "Steve" wrote:
>> >> well !!! lo-and-behold!!! when you get your error message back THIS
>> >> time,
>> >> you actually get a line number OTHER THAN 1 !!! now THAT would be
>> >> helpful!
>> >> imagine too, that you echo this out to the browser, copy it, and paste
>> >> it
>> >> directly into your mysql query browser...then execute it. even before
>> >> then,
>> >> you might have discovered (since you can now READ IT) that there is
>> >> something wrong in the data you're inserting.
>>
>> > Having yelled that out, haven't you ever noticed that mysql (and so do
>> > other
>> > sql servers) specify precisely where the problem is - this time it
>> > said:
>>
>> >> near 'from, size, format, cat, host ...
>>
>> you obviously haven't written very long or complex queries. 'near' and ON
>> LINE x are *worlds* apart, now aren't they.
>>
>> > ... so it was quite clear that it had had problem with "from".
>>
>> apparently not quite as clear to the op. :)
>>
>> > Considering php and
>> > queries code readability you are, of course, right, since a programmer
>> > will much more
>> > easily read the code formatted in the way you have, but considering
>> > error information,
>>
>> you should ammend that...'considering the error information [IN THIS
>> CASE]'.
>>
>> either way, it should be formatted as a rule...unless you're saying you
>> can
>> predict your errors, in which case you wouldn't make mistakes anyway.
>>
>> > sql servers are pretty precise about where the problem occurred, code
>> > being indented
>> > or not.
>>
>> really? which ones? what is 'pretty' precise?
>>
>> the indenting is multipurpose. it is my experience that the top 4 sql
>> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in their
>> error messages...but they all give line numbers!
>>
>> >> don't let me throw you on that one...bad data is NOT the problem here.
>> >> there
>> >> are things called RESERVED WORDS. one of those would be the word
>> >> 'FROM'...as
>> >> in "select * FROM". if you had correctly formatted your sql statement,
>> >> the
>> >> line number in error would have been line 6...a much better clue.
>>
>> > As for rude yelling about making mistakes with reserved words, that is
>> > something that happens
>> > to many people, even experienced, from time to time, so no need to get
>> > upset about it.
>>
>> rude? lol.
>>
>> you even infer rudeness about the mistake itself. no, i capitalized FROM
>> so
>> that it stood out. if that hurt your ears, then you won't hear me
>> laughing
>> right now. my intention throughout the thread here has been to make a
>> point
>> about formatting. did you not notice that even though i told him what the
>> problem was, i did not tell him how to fix it? hmmmm...must not have been
>> the goal of my post. seems you've missed that point.
>>
>> > I once
>> > named two variables in C like "od" and "do", and couldn't find out
>> > what was wrong with it until
>> > I realised it was the "do" keyword.
>>
>> christ almighty! i suppose you proliferate the use of variables like $tmp
>> too. what a goof! 'do'? for the love of god, almost *every* language has
>> a
>> *do* loop construct. so, when you said, 'even experienced' above, you
>> were
>> not associating yourself among those. :)
>>
>> > Finally, it is not "reserved" word in any sql, as you can indeed name
>> > any field "from", as long
>> > as you make the parser know it. For an example, this is totally legal:
>>
>> > select name, img, descr, "from", size, format from table;
>>
>> why yes. now why would i NOT explain that to the op? must not have been
>> the
>> purpose of my post. what's more, i'd be encouraging BAD behavior. if you
>> think that's just my ho, why don't you prepose that question in a db
>> forum...bring your asbestos umbrella, cuz it'll rain fire from the first
>> response to the last. dba's are kinda picky that way.
>>
>> > just as long as you keep the double quotes around key words.
>>
>> ahhhh...you assume too much. oracle will fart on your double quotes. it
>> likes either single tics or single back tics (`). again, you just killed
>> a
>> great chance for scalability. you should be able to take your code base
>> and
>> plop it down in front of any db and nothing breaks. you've forced
>> yourself
>> to reprogram when switching from one db to another...which is the shits
>> when
>> you're prototyping on your local pc using mysql and pushing code to
>> production where teradata is the db being used.
>>
>> wanna keep going, darko?
>
> Yes, please.
>
> It wasn't my intention to encourage Einstein30000 to use such field
> names as "from" or "select",
> the idea was only that such errors happen even to experienced
> programmers, not indicating whether
> I consider myself one or not - it's pretty relative thing, as you
> know.

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.

Re: mySQL Problem

"The Natural Philosopher" wrote in message
news:1194484441.81272.6@demeter.uk.clara.net...
> Darko wrote:
>> On Nov 7, 10:37 pm, "Steve" wrote:
>>> "Darko" wrote in message
>>>
>>> news:1194463439.305946.20240@z9g2000hsf.googlegroups.com...
>>>
>>>
>>>
>>>> On Nov 7, 6:19 pm, "Steve" wrote:
>>>>> well !!! lo-and-behold!!! when you get your error message back THIS
>>>>> time,
>>>>> you actually get a line number OTHER THAN 1 !!! now THAT would be
>>>>> helpful!
>>>>> imagine too, that you echo this out to the browser, copy it, and paste
>>>>> it
>>>>> directly into your mysql query browser...then execute it. even before
>>>>> then,
>>>>> you might have discovered (since you can now READ IT) that there is
>>>>> something wrong in the data you're inserting.
>>>> Having yelled that out, haven't you ever noticed that mysql (and so do
>>>> other
>>>> sql servers) specify precisely where the problem is - this time it
>>>> said:
>>>>> near 'from, size, format, cat, host ...
>>> you obviously haven't written very long or complex queries. 'near' and
>>> ON
>>> LINE x are *worlds* apart, now aren't they.
>>>
>>>> ... so it was quite clear that it had had problem with "from".
>>> apparently not quite as clear to the op. :)
>>>
>>>> Considering php and
>>>> queries code readability you are, of course, right, since a programmer
>>>> will much more
>>>> easily read the code formatted in the way you have, but considering
>>>> error information,
>>> you should ammend that...'considering the error information [IN THIS
>>> CASE]'.
>>>
>>> either way, it should be formatted as a rule...unless you're saying you
>>> can
>>> predict your errors, in which case you wouldn't make mistakes anyway.
>>>
>>>> sql servers are pretty precise about where the problem occurred, code
>>>> being indented
>>>> or not.
>>> really? which ones? what is 'pretty' precise?
>>>
>>> the indenting is multipurpose. it is my experience that the top 4 sql
>>> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in
>>> their
>>> error messages...but they all give line numbers!
>>>
>>>>> don't let me throw you on that one...bad data is NOT the problem here.
>>>>> there
>>>>> are things called RESERVED WORDS. one of those would be the word
>>>>> 'FROM'...as
>>>>> in "select * FROM". if you had correctly formatted your sql statement,
>>>>> the
>>>>> line number in error would have been line 6...a much better clue.
>>>> As for rude yelling about making mistakes with reserved words, that is
>>>> something that happens
>>>> to many people, even experienced, from time to time, so no need to get
>>>> upset about it.
>>> rude? lol.
>>>
>>> you even infer rudeness about the mistake itself. no, i capitalized FROM
>>> so
>>> that it stood out. if that hurt your ears, then you won't hear me
>>> laughing
>>> right now. my intention throughout the thread here has been to make a
>>> point
>>> about formatting. did you not notice that even though i told him what
>>> the
>>> problem was, i did not tell him how to fix it? hmmmm...must not have
>>> been
>>> the goal of my post. seems you've missed that point.
>>>
>>>> I once
>>>> named two variables in C like "od" and "do", and couldn't find out
>>>> what was wrong with it until
>>>> I realised it was the "do" keyword.
>>> christ almighty! i suppose you proliferate the use of variables like
>>> $tmp
>>> too. what a goof! 'do'? for the love of god, almost *every* language has
>>> a
>>> *do* loop construct. so, when you said, 'even experienced' above, you
>>> were
>>> not associating yourself among those. :)
>>>
>>>> Finally, it is not "reserved" word in any sql, as you can indeed name
>>>> any field "from", as long
>>>> as you make the parser know it. For an example, this is totally legal:
>>>> select name, img, descr, "from", size, format from table;
>>> why yes. now why would i NOT explain that to the op? must not have been
>>> the
>>> purpose of my post. what's more, i'd be encouraging BAD behavior. if you
>>> think that's just my ho, why don't you prepose that question in a db
>>> forum...bring your asbestos umbrella, cuz it'll rain fire from the first
>>> response to the last. dba's are kinda picky that way.
>>>
>>>> just as long as you keep the double quotes around key words.
>>> ahhhh...you assume too much. oracle will fart on your double quotes. it
>>> likes either single tics or single back tics (`). again, you just killed
>>> a
>>> great chance for scalability. you should be able to take your code base
>>> and
>>> plop it down in front of any db and nothing breaks. you've forced
>>> yourself
>>> to reprogram when switching from one db to another...which is the shits
>>> when
>>> you're prototyping on your local pc using mysql and pushing code to
>>> production where teradata is the db being used.
>>>
>>> wanna keep going, darko?
>>
>> Yes, please.
>>
>> It wasn't my intention to encourage Einstein30000 to use such field
>> names as "from" or "select",
>> the idea was only that such errors happen even to experienced
>> programmers, not indicating whether
>> I consider myself one or not - it's pretty relative thing, as you
>> know.
>>
>> As for "od" and "do", you should first know that I am a Serb, and that
>> in Serbian language "od" means "from",
>> and "do" means "to", so "od 1 do 10" means "from 1 to 10". Thus, once
>> in a simple C program I needed such "from" and
>> "to" helper variables, and I named them "od" and "do". It would have
>> been much easier to avoid if I was writing in
>> English, which I usually do when making non-test programs, since then
>> it would be easier to "hear" it as the English
>> do. But, being switched to Serbian in my mind, I didn't see any danger
>> coming of it, and the
>> compiler was pretty vague about the error, as you know it can be, and
>> I hardly recognized it. This is,
>> if you'd really like to know.
>>
>> As for yelling, your uppercasing "FROM" explanation doesn't mention
>> the "your sql statement is F.U.C.K.E.D", "well !!! lo-and-behold!!!",
>> "a line number OTHER THAN 1 !!! now THAT would be helpful! ", "since
>> you can now READ IT", "bad data is NOT the problem here. there are
>> things called RESERVED WORDS. " statements, which I normally
>> considered yelling. It's just not polite to address people like that,
>> especially ones that came for advice and help.
>>
>> Regards,
>> Darko
>>
> I'm with darko here. It took me about 5 seconds flat to realise what was
> wrong.
>
>
>
> No need to blow it across 15 lines.
>
> Unless you are the sort person who can't count beyond ten without taking
> their socks off.
>
>
> Mysql barfs where its parser gets confused..that was at the word 'from'
> Simple.

right. and no one is arguing the simple nature of identifying the problem
here. however, it becomes very difficult, not only to read, but to maintain
and debug sql statements that are not well formatted...which helps more
quickly identify the root cause when it is less than obvious.

i'm not for or against anyone. i'm for a systemic approach that covers all
the bases and is a best practice. that's all. it has little to do with the
actual problem faced here with reserved words.

Re: mySQL Problem

"lawrence k" wrote in message
news:1194496438.926297.74650@o38g2000hse.googlegroups.com...
> On Nov 7, 12:19 pm, "Steve" wrote:
>> "Einstein30000" wrote in message
>>
>> news:1194453026.587359.180320@19g2000hsx.googlegroups.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.

Re: mySQL Problem

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


> "Einstein30000" wrote in message
> news:1194453026.587359.180320@19g2000hsx.googlegroups.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

Re: mySQL Problem

Steve wrote:
> "The Natural Philosopher" wrote in message
> news:1194484441.81272.6@demeter.uk.clara.net...
>> Darko wrote:
>>> On Nov 7, 10:37 pm, "Steve" wrote:
>>>> "Darko" wrote in message
>>>>
>>>> news:1194463439.305946.20240@z9g2000hsf.googlegroups.com...
>>>>
>>>>
>>>>
>>>>> On Nov 7, 6:19 pm, "Steve" wrote:
>>>>>> well !!! lo-and-behold!!! when you get your error message back THIS
>>>>>> time,
>>>>>> you actually get a line number OTHER THAN 1 !!! now THAT would be
>>>>>> helpful!
>>>>>> imagine too, that you echo this out to the browser, copy it, and paste
>>>>>> it
>>>>>> directly into your mysql query browser...then execute it. even before
>>>>>> then,
>>>>>> you might have discovered (since you can now READ IT) that there is
>>>>>> something wrong in the data you're inserting.
>>>>> Having yelled that out, haven't you ever noticed that mysql (and so do
>>>>> other
>>>>> sql servers) specify precisely where the problem is - this time it
>>>>> said:
>>>>>> near 'from, size, format, cat, host ...
>>>> you obviously haven't written very long or complex queries. 'near' and
>>>> ON
>>>> LINE x are *worlds* apart, now aren't they.
>>>>
>>>>> ... so it was quite clear that it had had problem with "from".
>>>> apparently not quite as clear to the op. :)
>>>>
>>>>> Considering php and
>>>>> queries code readability you are, of course, right, since a programmer
>>>>> will much more
>>>>> easily read the code formatted in the way you have, but considering
>>>>> error information,
>>>> you should ammend that...'considering the error information [IN THIS
>>>> CASE]'.
>>>>
>>>> either way, it should be formatted as a rule...unless you're saying you
>>>> can
>>>> predict your errors, in which case you wouldn't make mistakes anyway.
>>>>
>>>>> sql servers are pretty precise about where the problem occurred, code
>>>>> being indented
>>>>> or not.
>>>> really? which ones? what is 'pretty' precise?
>>>>
>>>> the indenting is multipurpose. it is my experience that the top 4 sql
>>>> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in
>>>> their
>>>> error messages...but they all give line numbers!
>>>>
>>>>>> don't let me throw you on that one...bad data is NOT the problem here.
>>>>>> there
>>>>>> are things called RESERVED WORDS. one of those would be the word
>>>>>> 'FROM'...as
>>>>>> in "select * FROM". if you had correctly formatted your sql statement,
>>>>>> the
>>>>>> line number in error would have been line 6...a much better clue.
>>>>> As for rude yelling about making mistakes with reserved words, that is
>>>>> something that happens
>>>>> to many people, even experienced, from time to time, so no need to get
>>>>> upset about it.
>>>> rude? lol.
>>>>
>>>> you even infer rudeness about the mistake itself. no, i capitalized FROM
>>>> so
>>>> that it stood out. if that hurt your ears, then you won't hear me
>>>> laughing
>>>> right now. my intention throughout the thread here has been to make a
>>>> point
>>>> about formatting. did you not notice that even though i told him what
>>>> the
>>>> problem was, i did not tell him how to fix it? hmmmm...must not have
>>>> been
>>>> the goal of my post. seems you've missed that point.
>>>>
>>>>> I once
>>>>> named two variables in C like "od" and "do", and couldn't find out
>>>>> what was wrong with it until
>>>>> I realised it was the "do" keyword.
>>>> christ almighty! i suppose you proliferate the use of variables like
>>>> $tmp
>>>> too. what a goof! 'do'? for the love of god, almost *every* language has
>>>> a
>>>> *do* loop construct. so, when you said, 'even experienced' above, you
>>>> were
>>>> not associating yourself among those. :)
>>>>
>>>>> Finally, it is not "reserved" word in any sql, as you can indeed name
>>>>> any field "from", as long
>>>>> as you make the parser know it. For an example, this is totally legal:
>>>>> select name, img, descr, "from", size, format from table;
>>>> why yes. now why would i NOT explain that to the op? must not have been
>>>> the
>>>> purpose of my post. what's more, i'd be encouraging BAD behavior. if you
>>>> think that's just my ho, why don't you prepose that question in a db
>>>> forum...bring your asbestos umbrella, cuz it'll rain fire from the first
>>>> response to the last. dba's are kinda picky that way.
>>>>
>>>>> just as long as you keep the double quotes around key words.
>>>> ahhhh...you assume too much. oracle will fart on your double quotes. it
>>>> likes either single tics or single back tics (`). again, you just killed
>>>> a
>>>> great chance for scalability. you should be able to take your code base
>>>> and
>>>> plop it down in front of any db and nothing breaks. you've forced
>>>> yourself
>>>> to reprogram when switching from one db to another...which is the shits
>>>> when
>>>> you're prototyping on your local pc using mysql and pushing code to
>>>> production where teradata is the db being used.
>>>>
>>>> wanna keep going, darko?
>>> Yes, please.
>>>
>>> It wasn't my intention to encourage Einstein30000 to use such field
>>> names as "from" or "select",
>>> the idea was only that such errors happen even to experienced
>>> programmers, not indicating whether
>>> I consider myself one or not - it's pretty relative thing, as you
>>> know.
>>>
>>> As for "od" and "do", you should first know that I am a Serb, and that
>>> in Serbian language "od" means "from",
>>> and "do" means "to", so "od 1 do 10" means "from 1 to 10". Thus, once
>>> in a simple C program I needed such "from" and
>>> "to" helper variables, and I named them "od" and "do". It would have
>>> been much easier to avoid if I was writing in
>>> English, which I usually do when making non-test programs, since then
>>> it would be easier to "hear" it as the English
>>> do. But, being switched to Serbian in my mind, I didn't see any danger
>>> coming of it, and the
>>> compiler was pretty vague about the error, as you know it can be, and
>>> I hardly recognized it. This is,
>>> if you'd really like to know.
>>>
>>> As for yelling, your uppercasing "FROM" explanation doesn't mention
>>> the "your sql statement is F.U.C.K.E.D", "well !!! lo-and-behold!!!",
>>> "a line number OTHER THAN 1 !!! now THAT would be helpful! ", "since
>>> you can now READ IT", "bad data is NOT the problem here. there are
>>> things called RESERVED WORDS. " statements, which I normally
>>> considered yelling. It's just not polite to address people like that,
>>> especially ones that came for advice and help.
>>>
>>> Regards,
>>> Darko
>>>
>> I'm with darko here. It took me about 5 seconds flat to realise what was
>> wrong.
>>
>>
>>
>> No need to blow it across 15 lines.
>>
>> Unless you are the sort person who can't count beyond ten without taking
>> their socks off.
>>
>>
>> Mysql barfs where its parser gets confused..that was at the word 'from'
>> Simple.
>
> right. and no one is arguing the simple nature of identifying the problem
> here. however, it becomes very difficult, not only to read, but to maintain
> and debug sql statements that are not well formatted...which helps more
> quickly identify the root cause when it is less than obvious.
>
> i'm not for or against anyone. i'm for a systemic approach that covers all
> the bases and is a best practice. that's all. it has little to do with the
> actual problem faced here with reserved words.
>
>
>

Sorry, Steve - I don't agree with your method of "properly formatting"
the SQL. It takes way too much space on the page. It is not "correct"
by virtually any programmer I know.

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

Re: mySQL Problem

AnrDaemon wrote:
> Greetings, Steve.
> In reply to Your message dated Wednesday, November 7, 2007, 20:19:23,
>
>
>> "Einstein30000" wrote in message
>> news:1194453026.587359.180320@19g2000hsx.googlegroups.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.
jstucklex@attglobal.net
==================

Re: mySQL Problem

"Jerry Stuckle" wrote in message
news:192dnW2kIL6akq7anZ2dnUVZ_sjinZ2d@comcast.com...
> Steve wrote:
>> "The Natural Philosopher" wrote in message
>> news:1194484441.81272.6@demeter.uk.clara.net...
>>> Darko wrote:
>>>> On Nov 7, 10:37 pm, "Steve" wrote:
>>>>> "Darko" wrote in message
>>>>>
>>>>> news:1194463439.305946.20240@z9g2000hsf.googlegroups.com...
>>>>>
>>>>>
>>>>>
>>>>>> On Nov 7, 6:19 pm, "Steve" wrote:
>>>>>>> well !!! lo-and-behold!!! when you get your error message back THIS
>>>>>>> time,
>>>>>>> you actually get a line number OTHER THAN 1 !!! now THAT would be
>>>>>>> helpful!
>>>>>>> imagine too, that you echo this out to the browser, copy it, and
>>>>>>> paste it
>>>>>>> directly into your mysql query browser...then execute it. even
>>>>>>> before
>>>>>>> then,
>>>>>>> you might have discovered (since you can now READ IT) that there is
>>>>>>> something wrong in the data you're inserting.
>>>>>> Having yelled that out, haven't you ever noticed that mysql (and so
>>>>>> do
>>>>>> other
>>>>>> sql servers) specify precisely where the problem is - this time it
>>>>>> said:
>>>>>>> near 'from, size, format, cat, host ...
>>>>> you obviously haven't written very long or complex queries. 'near' and
>>>>> ON
>>>>> LINE x are *worlds* apart, now aren't they.
>>>>>
>>>>>> ... so it was quite clear that it had had problem with "from".
>>>>> apparently not quite as clear to the op. :)
>>>>>
>>>>>> Considering php and
>>>>>> queries code readability you are, of course, right, since a
>>>>>> programmer
>>>>>> will much more
>>>>>> easily read the code formatted in the way you have, but considering
>>>>>> error information,
>>>>> you should ammend that...'considering the error information [IN THIS
>>>>> CASE]'.
>>>>>
>>>>> either way, it should be formatted as a rule...unless you're saying
>>>>> you can
>>>>> predict your errors, in which case you wouldn't make mistakes anyway.
>>>>>
>>>>>> sql servers are pretty precise about where the problem occurred, code
>>>>>> being indented
>>>>>> or not.
>>>>> really? which ones? what is 'pretty' precise?
>>>>>
>>>>> the indenting is multipurpose. it is my experience that the top 4 sql
>>>>> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in
>>>>> their
>>>>> error messages...but they all give line numbers!
>>>>>
>>>>>>> don't let me throw you on that one...bad data is NOT the problem
>>>>>>> here.
>>>>>>> there
>>>>>>> are things called RESERVED WORDS. one of those would be the word
>>>>>>> 'FROM'...as
>>>>>>> in "select * FROM". if you had correctly formatted your sql
>>>>>>> statement,
>>>>>>> the
>>>>>>> line number in error would have been line 6...a much better clue.
>>>>>> As for rude yelling about making mistakes with reserved words, that
>>>>>> is
>>>>>> something that happens
>>>>>> to many people, even experienced, from time to time, so no need to
>>>>>> get
>>>>>> upset about it.
>>>>> rude? lol.
>>>>>
>>>>> you even infer rudeness about the mistake itself. no, i capitalized
>>>>> FROM so
>>>>> that it stood out. if that hurt your ears, then you won't hear me
>>>>> laughing
>>>>> right now. my intention throughout the thread here has been to make a
>>>>> point
>>>>> about formatting. did you not notice that even though i told him what
>>>>> the
>>>>> problem was, i did not tell him how to fix it? hmmmm...must not have
>>>>> been
>>>>> the goal of my post. seems you've missed that point.
>>>>>
>>>>>> I once
>>>>>> named two variables in C like "od" and "do", and couldn't find out
>>>>>> what was wrong with it until
>>>>>> I realised it was the "do" keyword.
>>>>> christ almighty! i suppose you proliferate the use of variables like
>>>>> $tmp
>>>>> too. what a goof! 'do'? for the love of god, almost *every* language
>>>>> has a
>>>>> *do* loop construct. so, when you said, 'even experienced' above, you
>>>>> were
>>>>> not associating yourself among those. :)
>>>>>
>>>>>> Finally, it is not "reserved" word in any sql, as you can indeed name
>>>>>> any field "from", as long
>>>>>> as you make the parser know it. For an example, this is totally
>>>>>> legal:
>>>>>> select name, img, descr, "from", size, format from table;
>>>>> why yes. now why would i NOT explain that to the op? must not have
>>>>> been the
>>>>> purpose of my post. what's more, i'd be encouraging BAD behavior. if
>>>>> you
>>>>> think that's just my ho, why don't you prepose that question in a db
>>>>> forum...bring your asbestos umbrella, cuz it'll rain fire from the
>>>>> first
>>>>> response to the last. dba's are kinda picky that way.
>>>>>
>>>>>> just as long as you keep the double quotes around key words.
>>>>> ahhhh...you assume too much. oracle will fart on your double quotes.
>>>>> it
>>>>> likes either single tics or single back tics (`). again, you just
>>>>> killed a
>>>>> great chance for scalability. you should be able to take your code
>>>>> base and
>>>>> plop it down in front of any db and nothing breaks. you've forced
>>>>> yourself
>>>>> to reprogram when switching from one db to another...which is the
>>>>> shits when
>>>>> you're prototyping on your local pc using mysql and pushing code to
>>>>> production where teradata is the db being used.
>>>>>
>>>>> wanna keep going, darko?
>>>> Yes, please.
>>>>
>>>> It wasn't my intention to encourage Einstein30000 to use such field
>>>> names as "from" or "select",
>>>> the idea was only that such errors happen even to experienced
>>>> programmers, not indicating whether
>>>> I consider myself one or not - it's pretty relative thing, as you
>>>> know.
>>>>
>>>> As for "od" and "do", you should first know that I am a Serb, and that
>>>> in Serbian language "od" means "from",
>>>> and "do" means "to", so "od 1 do 10" means "from 1 to 10". Thus, once
>>>> in a simple C program I needed such "from" and
>>>> "to" helper variables, and I named them "od" and "do". It would have
>>>> been much easier to avoid if I was writing in
>>>> English, which I usually do when making non-test programs, since then
>>>> it would be easier to "hear" it as the English
>>>> do. But, being switched to Serbian in my mind, I didn't see any danger
>>>> coming of it, and the
>>>> compiler was pretty vague about the error, as you know it can be, and
>>>> I hardly recognized it. This is,
>>>> if you'd really like to know.
>>>>
>>>> As for yelling, your uppercasing "FROM" explanation doesn't mention
>>>> the "your sql statement is F.U.C.K.E.D", "well !!! lo-and-behold!!!",
>>>> "a line number OTHER THAN 1 !!! now THAT would be helpful! ", "since
>>>> you can now READ IT", "bad data is NOT the problem here. there are
>>>> things called RESERVED WORDS. " statements, which I normally
>>>> considered yelling. It's just not polite to address people like that,
>>>> especially ones that came for advice and help.
>>>>
>>>> Regards,
>>>> Darko
>>>>
>>> I'm with darko here. It took me about 5 seconds flat to realise what was
>>> wrong.
>>>
>>>
>>>
>>> No need to blow it across 15 lines.
>>>
>>> Unless you are the sort person who can't count beyond ten without taking
>>> their socks off.
>>>
>>>
>>> Mysql barfs where its parser gets confused..that was at the word 'from'
>>> Simple.
>>
>> right. and no one is arguing the simple nature of identifying the problem
>> here. however, it becomes very difficult, not only to read, but to
>> maintain and debug sql statements that are not well formatted...which
>> helps more quickly identify the root cause when it is less than obvious.
>>
>> i'm not for or against anyone. i'm for a systemic approach that covers
>> all the bases and is a best practice. that's all. it has little to do
>> with the actual problem faced here with reserved words.
>
> Sorry, Steve - I don't agree with your method of "properly formatting" the
> SQL. It takes way too much space on the page. It is not "correct" by
> virtually any programmer I know.

too much space? is there a premium on space in your editor, jerry? would you
like me to post a query i have for running financial statistics here? i
would be more than willing to un-format it so just a single line in order to
save 'virtual' space on the 'virtual' page if you'd like. :)

as far as being 'correct by virtually any programmer i [you] know'...that
may be as 'virtual' as the space such a query takes up. as for what is
reported, documented, and written about code formatting - inclusive of sql -
i think you're outnumbered.

for the same reasons you should format sql, you format any other language
you write in. i'm sure you've written lots of scripts that are over several
hundred lines. why would you approach writing sql any differently than other
language? just curious jerry. if you have no other explanation than what
you've stated, you've hardly made a case...except a 'special case' which is
therefore, a logical fallacy.

Re: mySQL Problem

"AnrDaemon" wrote in message
news:628830764.20071108121442@freemail.ru...
> Greetings, Steve.
> In reply to Your message dated Wednesday, November 7, 2007, 20:19:23,
>
>
>> "Einstein30000" wrote in message
>> news:1194453026.587359.180320@19g2000hsx.googlegroups.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.

in that it currently doesn't work? is that all? it would help you be
understood better were you to allow a little more verbage than that. :)

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

as for 'anything else'. no, using reserved words as descriptives for db
objects (tables, columns, triggers, udf's, etc.) is such a huge no-no that a
dba would approach your boss and make a *strong* case for terminating your
ass. or, if you consult, a client thanking you for your time and parting
with your company in short order.

as for format? well, i'll be happy to one-line a couple of statistical
queries for you here. i'd venture a guess that if you can read it, you'd
have a shot at figuring out the calculations involved. if you don't (or
someone else with a question about it who can't simply read the query), then
i'd love to see you express to another person exactly where in the query you
don't get the actual logic that's going on. this is another reason to
format. 'hey, explain to me the calculation made on line 322.' that's v.
'hey, explain to me the calculations made near sum(avg(udf...no, not that
one...it's about the third one when your start at the top and search in your
editor for sum(avg(udf'. get the picture?

>> $sql = "
>> INSERT INTO main
>> (
>> `name` ,
>> `img` ,
>> `descr` ,
>> `from` ,
>> `size` ,
>> `format` ,
>> `cat` ,
>> `host` ,
>> `link` ,
>> `date`
>> )
>
> That way. All should work now.

until you forget what reserved words you've used and in which tables...or,
until you want (or your boss/client wants) to use another db. if you have a
large code base, how many man hours have you forced your employer to spend
fixing your (deliberate) oversight? hint, the larger the code base, the more
likely it is that you'll be looking for other means of income.

Re: mySQL Problem

On Nov 8, 5:33 am, lawrence k wrote:
> On Nov 7, 12:19 pm, "Steve" wrote:
>
>
>
> > "Einstein30000" wrote in message
>
> >news:1194453026.587359.180320@19g2000hsx.googlegroups.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).

Re: mySQL Problem

On Nov 8, 5:43 am, "Steve" wrote:
> "Darko" wrote in message
>
> news:1194479286.933437.249950@22g2000hsm.googlegroups.com...
>
>
>
> > On Nov 7, 10:37 pm, "Steve" wrote:
> >> "Darko" wrote in message
>
> >>news:1194463439.305946.20240@z9g2000hsf.googlegroups.com.. .
>
> >> > On Nov 7, 6:19 pm, "Steve" wrote:
> >> >> well !!! lo-and-behold!!! when you get your error message back THIS
> >> >> time,
> >> >> you actually get a line number OTHER THAN 1 !!! now THAT would be
> >> >> helpful!
> >> >> imagine too, that you echo this out to the browser, copy it, and paste
> >> >> it
> >> >> directly into your mysql query browser...then execute it. even before
> >> >> then,
> >> >> you might have discovered (since you can now READ IT) that there is
> >> >> something wrong in the data you're inserting.
>
> >> > Having yelled that out, haven't you ever noticed that mysql (and so do
> >> > other
> >> > sql servers) specify precisely where the problem is - this time it
> >> > said:
>
> >> >> near 'from, size, format, cat, host ...
>
> >> you obviously haven't written very long or complex queries. 'near' and ON
> >> LINE x are *worlds* apart, now aren't they.
>
> >> > ... so it was quite clear that it had had problem with "from".
>
> >> apparently not quite as clear to the op. :)
>
> >> > Considering php and
> >> > queries code readability you are, of course, right, since a programmer
> >> > will much more
> >> > easily read the code formatted in the way you have, but considering
> >> > error information,
>
> >> you should ammend that...'considering the error information [IN THIS
> >> CASE]'.
>
> >> either way, it should be formatted as a rule...unless you're saying you
> >> can
> >> predict your errors, in which case you wouldn't make mistakes anyway.
>
> >> > sql servers are pretty precise about where the problem occurred, code
> >> > being indented
> >> > or not.
>
> >> really? which ones? what is 'pretty' precise?
>
> >> the indenting is multipurpose. it is my experience that the top 4 sql
> >> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in their
> >> error messages...but they all give line numbers!
>
> >> >> don't let me throw you on that one...bad data is NOT the problem here.
> >> >> there
> >> >> are things called RESERVED WORDS. one of those would be the word
> >> >> 'FROM'...as
> >> >> in "select * FROM". if you had correctly formatted your sql statement,
> >> >> the
> >> >> line number in error would have been line 6...a much better clue.
>
> >> > As for rude yelling about making mistakes with reserved words, that is
> >> > something that happens
> >> > to many people, even experienced, from time to time, so no need to get
> >> > upset about it.
>
> >> rude? lol.
>
> >> you even infer rudeness about the mistake itself. no, i capitalized FROM
> >> so
> >> that it stood out. if that hurt your ears, then you won't hear me
> >> laughing
> >> right now. my intention throughout the thread here has been to make a
> >> point
> >> about formatting. did you not notice that even though i told him what the
> >> problem was, i did not tell him how to fix it? hmmmm...must not have been
> >> the goal of my post. seems you've missed that point.
>
> >> > I once
> >> > named two variables in C like "od" and "do", and couldn't find out
> >> > what was wrong with it until
> >> > I realised it was the "do" keyword.
>
> >> christ almighty! i suppose you proliferate the use of variables like $tmp
> >> too. what a goof! 'do'? for the love of god, almost *every* language has
> >> a
> >> *do* loop construct. so, when you said, 'even experienced' above, you
> >> were
> >> not associating yourself among those. :)
>
> >> > Finally, it is not "reserved" word in any sql, as you can indeed name
> >> > any field "from", as long
> >> > as you make the parser know it. For an example, this is totally legal:
>
> >> > select name, img, descr, "from", size, format from table;
>
> >> why yes. now why would i NOT explain that to the op? must not have been
> >> the
> >> purpose of my post. what's more, i'd be encouraging BAD behavior. if you
> >> think that's just my ho, why don't you prepose that question in a db
> >> forum...bring your asbestos umbrella, cuz it'll rain fire from the first
> >> response to the last. dba's are kinda picky that way.
>
> >> > just as long as you keep the double quotes around key words.
>
> >> ahhhh...you assume too much. oracle will fart on your double quotes. it
> >> likes either single tics or single back tics (`). again, you just killed
> >> a
> >> great chance for scalability. you should be able to take your code base
> >> and
> >> plop it down in front of any db and nothing breaks. you've forced
> >> yourself
> >> to reprogram when switching from one db to another...which is the shits
> >> when
> >> you're prototyping on your local pc using mysql and pushing code to
> >> production where teradata is the db being used.
>
> >> wanna keep going, darko?
>
> > Yes, please.
>
> > It wasn't my intention to encourage Einstein30000 to use such field
> > names as "from" or "select",
> > the idea was only that such errors happen even to experienced
> > programmers, not indicating whether
> > I consider myself one or not - it's pretty relative thing, as you
> > know.
>
> 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...

Re: mySQL Problem

On Nov 8, 2:28 pm, Jerry Stuckle wrote:
> Steve wrote:
> > "The Natural Philosopher" wrote in message
> >news:1194484441.81272.6@demeter.uk.clara.net...
> >> Darko wrote:
> >>> On Nov 7, 10:37 pm, "Steve" wrote:
> >>>> "Darko" wrote in message
>
> >>>>news:1194463439.305946.20240@z9g2000hsf.googlegroups.com ...
>
> >>>>> On Nov 7, 6:19 pm, "Steve" wrote:
> >>>>>> well !!! lo-and-behold!!! when you get your error message back THIS
> >>>>>> time,
> >>>>>> you actually get a line number OTHER THAN 1 !!! now THAT would be
> >>>>>> helpful!
> >>>>>> imagine too, that you echo this out to the browser, copy it, and paste
> >>>>>> it
> >>>>>> directly into your mysql query browser...then execute it. even before
> >>>>>> then,
> >>>>>> you might have discovered (since you can now READ IT) that there is
> >>>>>> something wrong in the data you're inserting.
> >>>>> Having yelled that out, haven't you ever noticed that mysql (and so do
> >>>>> other
> >>>>> sql servers) specify precisely where the problem is - this time it
> >>>>> said:
> >>>>>> near 'from, size, format, cat, host ...
> >>>> you obviously haven't written very long or complex queries. 'near' and
> >>>> ON
> >>>> LINE x are *worlds* apart, now aren't they.
>
> >>>>> ... so it was quite clear that it had had problem with "from".
> >>>> apparently not quite as clear to the op. :)
>
> >>>>> Considering php and
> >>>>> queries code readability you are, of course, right, since a programmer
> >>>>> will much more
> >>>>> easily read the code formatted in the way you have, but considering
> >>>>> error information,
> >>>> you should ammend that...'considering the error information [IN THIS
> >>>> CASE]'.
>
> >>>> either way, it should be formatted as a rule...unless you're saying you
> >>>> can
> >>>> predict your errors, in which case you wouldn't make mistakes anyway.
>
> >>>>> sql servers are pretty precise about where the problem occurred, code
> >>>>> being indented
> >>>>> or not.
> >>>> really? which ones? what is 'pretty' precise?
>
> >>>> the indenting is multipurpose. it is my experience that the top 4 sql
> >>>> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in
> >>>> their
> >>>> error messages...but they all give line numbers!
>
> >>>>>> don't let me throw you on that one...bad data is NOT the problem here.
> >>>>>> there
> >>>>>> are things called RESERVED WORDS. one of those would be the word
> >>>>>> 'FROM'...as
> >>>>>> in "select * FROM". if you had correctly formatted your sql statement,
> >>>>>> the
> >>>>>> line number in error would have been line 6...a much better clue.
> >>>>> As for rude yelling about making mistakes with reserved words, that is
> >>>>> something that happens
> >>>>> to many people, even experienced, from time to time, so no need to get
> >>>>> upset about it.
> >>>> rude? lol.
>
> >>>> you even infer rudeness about the mistake itself. no, i capitalized FROM
> >>>> so
> >>>> that it stood out. if that hurt your ears, then you won't hear me
> >>>> laughing
> >>>> right now. my intention throughout the thread here has been to make a
> >>>> point
> >>>> about formatting. did you not notice that even though i told him what
> >>>> the
> >>>> problem was, i did not tell him how to fix it? hmmmm...must not have
> >>>> been
> >>>> the goal of my post. seems you've missed that point.
>
> >>>>> I once
> >>>>> named two variables in C like "od" and "do", and couldn't find out
> >>>>> what was wrong with it until
> >>>>> I realised it was the "do" keyword.
> >>>> christ almighty! i suppose you proliferate the use of variables like
> >>>> $tmp
> >>>> too. what a goof! 'do'? for the love of god, almost *every* language has
> >>>> a
> >>>> *do* loop construct. so, when you said, 'even experienced' above, you
> >>>> were
> >>>> not associating yourself among those. :)
>
> >>>>> Finally, it is not "reserved" word in any sql, as you can indeed name
> >>>>> any field "from", as long
> >>>>> as you make the parser know it. For an example, this is totally legal:
> >>>>> select name, img, descr, "from", size, format from table;
> >>>> why yes. now why would i NOT explain that to the op? must not have been
> >>>> the
> >>>> purpose of my post. what's more, i'd be encouraging BAD behavior. if you
> >>>> think that's just my ho, why don't you prepose that question in a db
> >>>> forum...bring your asbestos umbrella, cuz it'll rain fire from the first
> >>>> response to the last. dba's are kinda picky that way.
>
> >>>>> just as long as you keep the double quotes around key words.
> >>>> ahhhh...you assume too much. oracle will fart on your double quotes. it
> >>>> likes either single tics or single back tics (`). again, you just killed
> >>>> a
> >>>> great chance for scalability. you should be able to take your code base
> >>>> and
> >>>> plop it down in front of any db and nothing breaks. you've forced
> >>>> yourself
> >>>> to reprogram when switching from one db to another...which is the shits
> >>>> when
> >>>> you're prototyping on your local pc using mysql and pushing code to
> >>>> production where teradata is the db being used.
>
> >>>> wanna keep going, darko?
> >>> Yes, please.
>
> >>> It wasn't my intention to encourage Einstein30000 to use such field
> >>> names as "from" or "select",
> >>> the idea was only that such errors happen even to experienced
> >>> programmers, not indicating whether
> >>> I consider myself one or not - it's pretty relative thing, as you
> >>> know.
>
> >>> As for "od" and "do", you should first know that I am a Serb, and that
> >>> in Serbian language "od" means "from",
> >>> and "do" means "to", so "od 1 do 10" means "from 1 to 10". Thus, once
> >>> in a simple C program I needed such "from" and
> >>> "to" helper variables, and I named them "od" and "do". It would have
> >>> been much easier to avoid if I was writing in
> >>> English, which I usually do when making non-test programs, since then
> >>> it would be easier to "hear" it as the English
> >>> do. But, being switched to Serbian in my mind, I didn't see any danger
> >>> coming of it, and the
> >>> compiler was pretty vague about the error, as you know it can be, and
> >>> I hardly recognized it. This is,
> >>> if you'd really like to know.
>
> >>> As for yelling, your uppercasing "FROM" explanation doesn't mention
> >>> the "your sql statement is F.U.C.K.E.D", "well !!! lo-and-behold!!!",
> >>> "a line number OTHER THAN 1 !!! now THAT would be helpful! ", "since
> >>> you can now READ IT", "bad data is NOT the problem here. there are
> >>> things called RESERVED WORDS. " statements, which I normally
> >>> considered yelling. It's just not polite to address people like that,
> >>> especially ones that came for advice and help.
>
> >>> Regards,
> >>> Darko
>
> >> I'm with darko here. It took me about 5 seconds flat to realise what was
> >> wrong.
>
> >> No need to blow it across 15 lines.
>
> >> Unless you are the sort person who can't count beyond ten without taking
> >> their socks off.
>
> >> Mysql barfs where its parser gets confused..that was at the word 'from'
> >> Simple.
>
> > right. and no one is arguing the simple nature of identifying the problem
> > here. however, it becomes very difficult, not only to read, but to maintain
> > and debug sql statements that are not well formatted...which helps more
> > quickly identify the root cause when it is less than obvious.
>
> > i'm not for or against anyone. i'm for a systemic approach that covers all
> > the bases and is a best practice. that's all. it has little to do with the
> > actual problem faced here with reserved words.
>
> Sorry, Steve - I don't agree with your method of "properly formatting"
> the SQL. It takes way too much space on the page. It is not "correct"
> by virtually any programmer I know.
>
> --
> ==================
> 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

Re: mySQL Problem

"Darko" wrote in message
news:1194532723.267277.253060@k35g2000prh.googlegroups.com.. .
> On Nov 8, 5:43 am, "Steve" wrote:
>> "Darko" wrote in message
>>
>> news:1194479286.933437.249950@22g2000hsm.googlegroups.com...
>>
>>
>>
>> > On Nov 7, 10:37 pm, "Steve" wrote:
>> >> "Darko" wrote in message
>>
>> >>news:1194463439.305946.20240@z9g2000hsf.googlegroups.com.. .
>>
>> >> > On Nov 7, 6:19 pm, "Steve" wrote:
>> >> >> well !!! lo-and-behold!!! when you get your error message back THIS
>> >> >> time,
>> >> >> you actually get a line number OTHER THAN 1 !!! now THAT would be
>> >> >> helpful!
>> >> >> imagine too, that you echo this out to the browser, copy it, and
>> >> >> paste
>> >> >> it
>> >> >> directly into your mysql query browser...then execute it. even
>> >> >> before
>> >> >> then,
>> >> >> you might have discovered (since you can now READ IT) that there is
>> >> >> something wrong in the data you're inserting.
>>
>> >> > Having yelled that out, haven't you ever noticed that mysql (and so
>> >> > do
>> >> > other
>> >> > sql servers) specify precisely where the problem is - this time it
>> >> > said:
>>
>> >> >> near 'from, size, format, cat, host ...
>>
>> >> you obviously haven't written very long or complex queries. 'near' and
>> >> ON
>> >> LINE x are *worlds* apart, now aren't they.
>>
>> >> > ... so it was quite clear that it had had problem with "from".
>>
>> >> apparently not quite as clear to the op. :)
>>
>> >> > Considering php and
>> >> > queries code readability you are, of course, right, since a
>> >> > programmer
>> >> > will much more
>> >> > easily read the code formatted in the way you have, but considering
>> >> > error information,
>>
>> >> you should ammend that...'considering the error information [IN THIS
>> >> CASE]'.
>>
>> >> either way, it should be formatted as a rule...unless you're saying
>> >> you
>> >> can
>> >> predict your errors, in which case you wouldn't make mistakes anyway.
>>
>> >> > sql servers are pretty precise about where the problem occurred,
>> >> > code
>> >> > being indented
>> >> > or not.
>>
>> >> really? which ones? what is 'pretty' precise?
>>
>> >> the indenting is multipurpose. it is my experience that the top 4 sql
>> >> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in
>> >> their
>> >> error messages...but they all give line numbers!
>>
>> >> >> don't let me throw you on that one...bad data is NOT the problem
>> >> >> here.
>> >> >> there
>> >> >> are things called RESERVED WORDS. one of those would be the word
>> >> >> 'FROM'...as
>> >> >> in "select * FROM". if you had correctly formatted your sql
>> >> >> statement,
>> >> >> the
>> >> >> line number in error would have been line 6...a much better clue.
>>
>> >> > As for rude yelling about making mistakes with reserved words, that
>> >> > is
>> >> > something that happens
>> >> > to many people, even experienced, from time to time, so no need to
>> >> > get
>> >> > upset about it.
>>
>> >> rude? lol.
>>
>> >> you even infer rudeness about the mistake itself. no, i capitalized
>> >> FROM
>> >> so
>> >> that it stood out. if that hurt your ears, then you won't hear me
>> >> laughing
>> >> right now. my intention throughout the thread here has been to make a
>> >> point
>> >> about formatting. did you not notice that even though i told him what
>> >> the
>> >> problem was, i did not tell him how to fix it? hmmmm...must not have
>> >> been
>> >> the goal of my post. seems you've missed that point.
>>
>> >> > I once
>> >> > named two variables in C like "od" and "do", and couldn't find out
>> >> > what was wrong with it until
>> >> > I realised it was the "do" keyword.
>>
>> >> christ almighty! i suppose you proliferate the use of variables like
>> >> $tmp
>> >> too. what a goof! 'do'? for the love of god, almost *every* language
>> >> has
>> >> a
>> >> *do* loop construct. so, when you said, 'even experienced' above, you
>> >> were
>> >> not associating yourself among those. :)
>>
>> >> > Finally, it is not "reserved" word in any sql, as you can indeed
>> >> > name
>> >> > any field "from", as long
>> >> > as you make the parser know it. For an example, this is totally
>> >> > legal:
>>
>> >> > select name, img, descr, "from", size, format from table;
>>
>> >> why yes. now why would i NOT explain that to the op? must not have
>> >> been
>> >> the
>> >> purpose of my post. what's more, i'd be encouraging BAD behavior. if
>> >> you
>> >> think that's just my ho, why don't you prepose that question in a db
>> >> forum...bring your asbestos umbrella, cuz it'll rain fire from the
>> >> first
>> >> response to the last. dba's are kinda picky that way.
>>
>> >> > just as long as you keep the double quotes around key words.
>>
>> >> ahhhh...you assume too much. oracle will fart on your double quotes.
>> >> it
>> >> likes either single tics or single back tics (`). again, you just
>> >> killed
>> >> a
>> >> great chance for scalability. you should be able to take your code
>> >> base
>> >> and
>> >> plop it down in front of any db and nothing breaks. you've forced
>> >> yourself
>> >> to reprogram when switching from one db to another...which is the
>> >> shits
>> >> when
>> >> you're prototyping on your local pc using mysql and pushing code to
>> >> production where teradata is the db being used.
>>
>> >> wanna keep going, darko?
>>
>> > Yes, please.
>>
>> > It wasn't my intention to encourage Einstein30000 to use such field
>> > names as "from" or "select",
>> > the idea was only that such errors happen even to experienced
>> > programmers, not indicating whether
>> > I consider myself one or not - it's pretty relative thing, as you
>> > know.
>>
>> 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

Re: mySQL Problem

"Darko" wrote in message
news:1194533103.787182.143900@i13g2000prf.googlegroups.com.. .
> On Nov 8, 2:28 pm, Jerry Stuckle wrote:
>> Steve wrote:
>> > "The Natural Philosopher" wrote in message
>> >news:1194484441.81272.6@demeter.uk.clara.net...
>> >> Darko wrote:
>> >>> On Nov 7, 10:37 pm, "Steve" wrote:
>> >>>> "Darko" wrote in message
>>
>> >>>>news:1194463439.305946.20240@z9g2000hsf.googlegroups.com ...
>>
>> >>>>> On Nov 7, 6:19 pm, "Steve" wrote:
>> >>>>>> well !!! lo-and-behold!!! when you get your error message back
>> >>>>>> THIS
>> >>>>>> time,
>> >>>>>> you actually get a line number OTHER THAN 1 !!! now THAT would be
>> >>>>>> helpful!
>> >>>>>> imagine too, that you echo this out to the browser, copy it, and
>> >>>>>> paste
>> >>>>>> it
>> >>>>>> directly into your mysql query browser...then execute it. even
>> >>>>>> before
>> >>>>>> then,
>> >>>>>> you might have discovered (since you can now READ IT) that there
>> >>>>>> is
>> >>>>>> something wrong in the data you're inserting.
>> >>>>> Having yelled that out, haven't you ever noticed that mysql (and so
>> >>>>> do
>> >>>>> other
>> >>>>> sql servers) specify precisely where the problem is - this time it
>> >>>>> said:
>> >>>>>> near 'from, size, format, cat, host ...
>> >>>> you obviously haven't written very long or complex queries. 'near'
>> >>>> and
>> >>>> ON
>> >>>> LINE x are *worlds* apart, now aren't they.
>>
>> >>>>> ... so it was quite clear that it had had problem with "from".
>> >>>> apparently not quite as clear to the op. :)
>>
>> >>>>> Considering php and
>> >>>>> queries code readability you are, of course, right, since a
>> >>>>> programmer
>> >>>>> will much more
>> >>>>> easily read the code formatted in the way you have, but considering
>> >>>>> error information,
>> >>>> you should ammend that...'considering the error information [IN THIS
>> >>>> CASE]'.
>>
>> >>>> either way, it should be formatted as a rule...unless you're saying
>> >>>> you
>> >>>> can
>> >>>> predict your errors, in which case you wouldn't make mistakes
>> >>>> anyway.
>>
>> >>>>> sql servers are pretty precise about where the problem occurred,
>> >>>>> code
>> >>>>> being indented
>> >>>>> or not.
>> >>>> really? which ones? what is 'pretty' precise?
>>
>> >>>> the indenting is multipurpose. it is my experience that the top 4
>> >>>> sql
>> >>>> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in
>> >>>> their
>> >>>> error messages...but they all give line numbers!
>>
>> >>>>>> don't let me throw you on that one...bad data is NOT the problem
>> >>>>>> here.
>> >>>>>> there
>> >>>>>> are things called RESERVED WORDS. one of those would be the word
>> >>>>>> 'FROM'...as
>> >>>>>> in "select * FROM". if you had correctly formatted your sql
>> >>>>>> statement,
>> >>>>>> the
>> >>>>>> line number in error would have been line 6...a much better clue.
>> >>>>> As for rude yelling about making mistakes with reserved words, that
>> >>>>> is
>> >>>>> something that happens
>> >>>>> to many people, even experienced, from time to time, so no need to
>> >>>>> get
>> >>>>> upset about it.
>> >>>> rude? lol.
>>
>> >>>> you even infer rudeness about the mistake itself. no, i capitalized
>> >>>> FROM
>> >>>> so
>> >>>> that it stood out. if that hurt your ears, then you won't hear me
>> >>>> laughing
>> >>>> right now. my intention throughout the thread here has been to make
>> >>>> a
>> >>>> point
>> >>>> about formatting. did you not notice that even though i told him
>> >>>> what
>> >>>> the
>> >>>> problem was, i did not tell him how to fix it? hmmmm...must not have
>> >>>> been
>> >>>> the goal of my post. seems you've missed that point.
>>
>> >>>>> I once
>> >>>>> named two variables in C like "od" and "do", and couldn't find out
>> >>>>> what was wrong with it until
>> >>>>> I realised it was the "do" keyword.
>> >>>> christ almighty! i suppose you proliferate the use of variables like
>> >>>> $tmp
>> >>>> too. what a goof! 'do'? for the love of god, almost *every* language
>> >>>> has
>> >>>> a
>> >>>> *do* loop construct. so, when you said, 'even experienced' above,
>> >>>> you
>> >>>> were
>> >>>> not associating yourself among those. :)
>>
>> >>>>> Finally, it is not "reserved" word in any sql, as you can indeed
>> >>>>> name
>> >>>>> any field "from", as long
>> >>>>> as you make the parser know it. For an example, this is totally
>> >>>>> legal:
>> >>>>> select name, img, descr, "from", size, format from table;
>> >>>> why yes. now why would i NOT explain that to the op? must not have
>> >>>> been
>> >>>> the
>> >>>> purpose of my post. what's more, i'd be encouraging BAD behavior. if
>> >>>> you
>> >>>> think that's just my ho, why don't you prepose that question in a db
>> >>>> forum...bring your asbestos umbrella, cuz it'll rain fire from the
>> >>>> first
>> >>>> response to the last. dba's are kinda picky that way.
>>
>> >>>>> just as long as you keep the double quotes around key words.
>> >>>> ahhhh...you assume too much. oracle will fart on your double quotes.
>> >>>> it
>> >>>> likes either single tics or single back tics (`). again, you just
>> >>>> killed
>> >>>> a
>> >>>> great chance for scalability. you should be able to take your code
>> >>>> base
>> >>>> and
>> >>>> plop it down in front of any db and nothing breaks. you've forced
>> >>>> yourself
>> >>>> to reprogram when switching from one db to another...which is the
>> >>>> shits
>> >>>> when
>> >>>> you're prototyping on your local pc using mysql and pushing code to
>> >>>> production where teradata is the db being used.
>>
>> >>>> wanna keep going, darko?
>> >>> Yes, please.
>>
>> >>> It wasn't my intention to encourage Einstein30000 to use such field
>> >>> names as "from" or "select",
>> >>> the idea was only that such errors happen even to experienced
>> >>> programmers, not indicating whether
>> >>> I consider myself one or not - it's pretty relative thing, as you
>> >>> know.
>>
>> >>> As for "od" and "do", you should first know that I am a Serb, and
>> >>> that
>> >>> in Serbian language "od" means "from",
>> >>> and "do" means "to", so "od 1 do 10" means "from 1 to 10". Thus, once
>> >>> in a simple C program I needed such "from" and
>> >>> "to" helper variables, and I named them "od" and "do". It would have
>> >>> been much easier to avoid if I was writing in
>> >>> English, which I usually do when making non-test programs, since then
>> >>> it would be easier to "hear" it as the English
>> >>> do. But, being switched to Serbian in my mind, I didn't see any
>> >>> danger
>> >>> coming of it, and the
>> >>> compiler was pretty vague about the error, as you know it can be, and
>> >>> I hardly recognized it. This is,
>> >>> if you'd really like to know.
>>
>> >>> As for yelling, your uppercasing "FROM" explanation doesn't mention
>> >>> the "your sql statement is F.U.C.K.E.D", "well !!! lo-and-behold!!!",
>> >>> "a line number OTHER THAN 1 !!! now THAT would be helpful! ", "since
>> >>> you can now READ IT", "bad data is NOT the problem here. there are
>> >>> things called RESERVED WORDS. " statements, which I normally
>> >>> considered yelling. It's just not polite to address people like that,
>> >>> especially ones that came for advice and help.
>>
>> >>> Regards,
>> >>> Darko
>>
>> >> I'm with darko here. It took me about 5 seconds flat to realise what
>> >> was
>> >> wrong.
>>
>> >> No need to blow it across 15 lines.
>>
>> >> Unless you are the sort person who can't count beyond ten without
>> >> taking
>> >> their socks off.
>>
>> >> Mysql barfs where its parser gets confused..that was at the word
>> >> 'from'
>> >> Simple.
>>
>> > right. and no one is arguing the simple nature of identifying the
>> > problem
>> > here. however, it becomes very difficult, not only to read, but to
>> > maintain
>> > and debug sql statements that are not well formatted...which helps more
>> > quickly identify the root cause when it is less than obvious.
>>
>> > i'm not for or against anyone. i'm for a systemic approach that covers
>> > all
>> > the bases and is a best practice. that's all. it has little to do with
>> > the
>> > actual problem faced here with reserved words.
>>
>> Sorry, Steve - I don't agree with your method of "properly formatting"
>> the SQL. It takes way too much space on the page. It is not "correct"
>> by virtually any programmer I know.
>>
>> --
>> ==================
>> 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)

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 '

' . print_r($sql, true) . '

Re: mySQL Problem

Steve wrote:
> "Jerry Stuckle" wrote in message
> news:192dnW2kIL6akq7anZ2dnUVZ_sjinZ2d@comcast.com...
>> Steve wrote:
>>> "The Natural Philosopher" wrote in message
>>> news:1194484441.81272.6@demeter.uk.clara.net...
>>>> Darko wrote:
>>>>> On Nov 7, 10:37 pm, "Steve" wrote:
>>>>>> "Darko" wrote in message
>>>>>>
>>>>>> news:1194463439.305946.20240@z9g2000hsf.googlegroups.com...
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Nov 7, 6:19 pm, "Steve" wrote:
>>>>>>>> well !!! lo-and-behold!!! when you get your error message back THIS
>>>>>>>> time,
>>>>>>>> you actually get a line number OTHER THAN 1 !!! now THAT would be
>>>>>>>> helpful!
>>>>>>>> imagine too, that you echo this out to the browser, copy it, and
>>>>>>>> paste it
>>>>>>>> directly into your mysql query browser...then execute it. even
>>>>>>>> before
>>>>>>>> then,
>>>>>>>> you might have discovered (since you can now READ IT) that there is
>>>>>>>> something wrong in the data you're inserting.
>>>>>>> Having yelled that out, haven't you ever noticed that mysql (and so
>>>>>>> do
>>>>>>> other
>>>>>>> sql servers) specify precisely where the problem is - this time it
>>>>>>> said:
>>>>>>>> near 'from, size, format, cat, host ...
>>>>>> you obviously haven't written very long or complex queries. 'near' and
>>>>>> ON
>>>>>> LINE x are *worlds* apart, now aren't they.
>>>>>>
>>>>>>> ... so it was quite clear that it had had problem with "from".
>>>>>> apparently not quite as clear to the op. :)
>>>>>>
>>>>>>> Considering php and
>>>>>>> queries code readability you are, of course, right, since a
>>>>>>> programmer
>>>>>>> will much more
>>>>>>> easily read the code formatted in the way you have, but considering
>>>>>>> error information,
>>>>>> you should ammend that...'considering the error information [IN THIS
>>>>>> CASE]'.
>>>>>>
>>>>>> either way, it should be formatted as a rule...unless you're saying
>>>>>> you can
>>>>>> predict your errors, in which case you wouldn't make mistakes anyway.
>>>>>>
>>>>>>> sql servers are pretty precise about where the problem occurred, code
>>>>>>> being indented
>>>>>>> or not.
>>>>>> really? which ones? what is 'pretty' precise?
>>>>>>
>>>>>> the indenting is multipurpose. it is my experience that the top 4 sql
>>>>>> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in
>>>>>> their
>>>>>> error messages...but they all give line numbers!
>>>>>>
>>>>>>>> don't let me throw you on that one...bad data is NOT the problem
>>>>>>>> here.
>>>>>>>> there
>>>>>>>> are things called RESERVED WORDS. one of those would be the word
>>>>>>>> 'FROM'...as
>>>>>>>> in "select * FROM". if you had correctly formatted your sql
>>>>>>>> statement,
>>>>>>>> the
>>>>>>>> line number in error would have been line 6...a much better clue.
>>>>>>> As for rude yelling about making mistakes with reserved words, that
>>>>>>> is
>>>>>>> something that happens
>>>>>>> to many people, even experienced, from time to time, so no need to
>>>>>>> get
>>>>>>> upset about it.
>>>>>> rude? lol.
>>>>>>
>>>>>> you even infer rudeness about the mistake itself. no, i capitalized
>>>>>> FROM so
>>>>>> that it stood out. if that hurt your ears, then you won't hear me
>>>>>> laughing
>>>>>> right now. my intention throughout the thread here has been to make a
>>>>>> point
>>>>>> about formatting. did you not notice that even though i told him what
>>>>>> the
>>>>>> problem was, i did not tell him how to fix it? hmmmm...must not have
>>>>>> been
>>>>>> the goal of my post. seems you've missed that point.
>>>>>>
>>>>>>> I once
>>>>>>> named two variables in C like "od" and "do", and couldn't find out
>>>>>>> what was wrong with it until
>>>>>>> I realised it was the "do" keyword.
>>>>>> christ almighty! i suppose you proliferate the use of variables like
>>>>>> $tmp
>>>>>> too. what a goof! 'do'? for the love of god, almost *every* language
>>>>>> has a
>>>>>> *do* loop construct. so, when you said, 'even experienced' above, you
>>>>>> were
>>>>>> not associating yourself among those. :)
>>>>>>
>>>>>>> Finally, it is not "reserved" word in any sql, as you can indeed name
>>>>>>> any field "from", as long
>>>>>>> as you make the parser know it. For an example, this is totally
>>>>>>> legal:
>>>>>>> select name, img, descr, "from", size, format from table;
>>>>>> why yes. now why would i NOT explain that to the op? must not have
>>>>>> been the
>>>>>> purpose of my post. what's more, i'd be encouraging BAD behavior. if
>>>>>> you
>>>>>> think that's just my ho, why don't you prepose that question in a db
>>>>>> forum...bring your asbestos umbrella, cuz it'll rain fire from the
>>>>>> first
>>>>>> response to the last. dba's are kinda picky that way.
>>>>>>
>>>>>>> just as long as you keep the double quotes around key words.
>>>>>> ahhhh...you assume too much. oracle will fart on your double quotes.
>>>>>> it
>>>>>> likes either single tics or single back tics (`). again, you just
>>>>>> killed a
>>>>>> great chance for scalability. you should be able to take your code
>>>>>> base and
>>>>>> plop it down in front of any db and nothing breaks. you've forced
>>>>>> yourself
>>>>>> to reprogram when switching from one db to another...which is the
>>>>>> shits when
>>>>>> you're prototyping on your local pc using mysql and pushing code to
>>>>>> production where teradata is the db being used.
>>>>>>
>>>>>> wanna keep going, darko?
>>>>> Yes, please.
>>>>>
>>>>> It wasn't my intention to encourage Einstein30000 to use such field
>>>>> names as "from" or "select",
>>>>> the idea was only that such errors happen even to experienced
>>>>> programmers, not indicating whether
>>>>> I consider myself one or not - it's pretty relative thing, as you
>>>>> know.
>>>>>
>>>>> As for "od" and "do", you should first know that I am a Serb, and that
>>>>> in Serbian language "od" means "from",
>>>>> and "do" means "to", so "od 1 do 10" means "from 1 to 10". Thus, once
>>>>> in a simple C program I needed such "from" and
>>>>> "to" helper variables, and I named them "od" and "do". It would have
>>>>> been much easier to avoid if I was writing in
>>>>> English, which I usually do when making non-test programs, since then
>>>>> it would be easier to "hear" it as the English
>>>>> do. But, being switched to Serbian in my mind, I didn't see any danger
>>>>> coming of it, and the
>>>>> compiler was pretty vague about the error, as you know it can be, and
>>>>> I hardly recognized it. This is,
>>>>> if you'd really like to know.
>>>>>
>>>>> As for yelling, your uppercasing "FROM" explanation doesn't mention
>>>>> the "your sql statement is F.U.C.K.E.D", "well !!! lo-and-behold!!!",
>>>>> "a line number OTHER THAN 1 !!! now THAT would be helpful! ", "since
>>>>> you can now READ IT", "bad data is NOT the problem here. there are
>>>>> things called RESERVED WORDS. " statements, which I normally
>>>>> considered yelling. It's just not polite to address people like that,
>>>>> especially ones that came for advice and help.
>>>>>
>>>>> Regards,
>>>>> Darko
>>>>>
>>>> I'm with darko here. It took me about 5 seconds flat to realise what was
>>>> wrong.
>>>>
>>>>
>>>>
>>>> No need to blow it across 15 lines.
>>>>
>>>> Unless you are the sort person who can't count beyond ten without taking
>>>> their socks off.
>>>>
>>>>
>>>> Mysql barfs where its parser gets confused..that was at the word 'from'
>>>> Simple.
>>> right. and no one is arguing the simple nature of identifying the problem
>>> here. however, it becomes very difficult, not only to read, but to
>>> maintain and debug sql statements that are not well formatted...which
>>> helps more quickly identify the root cause when it is less than obvious.
>>>
>>> i'm not for or against anyone. i'm for a systemic approach that covers
>>> all the bases and is a best practice. that's all. it has little to do
>>> with the actual problem faced here with reserved words.
>> Sorry, Steve - I don't agree with your method of "properly formatting" the
>> SQL. It takes way too much space on the page. It is not "correct" by
>> virtually any programmer I know.
>
> too much space? is there a premium on space in your editor, jerry? would you
> like me to post a query i have for running financial statistics here? i
> would be more than willing to un-format it so just a single line in order to
> save 'virtual' space on the 'virtual' page if you'd like. :)
>

Don't be an asshole again, Steve. My editor isn't limited, but my
screen size is, and that wastes a lot of it.

> as far as being 'correct by virtually any programmer i [you] know'...that
> may be as 'virtual' as the space such a query takes up. as for what is
> reported, documented, and written about code formatting - inclusive of sql -
> i think you're outnumbered.
>

Yep, programmers with any sense don't do it that way. The do it similar to:

SELECT a,b,c
FROM x
WHERE y='z';

Or something similar. And in the almost 25 years I've been doing SQL, I
can probably count on two hands the number of experienced programmers
who write SQL as you did. And hundreds who do it the way I learned.

> for the same reasons you should format sql, you format any other language
> you write in. i'm sure you've written lots of scripts that are over several
> hundred lines. why would you approach writing sql any differently than other
> language? just curious jerry. if you have no other explanation than what
> you've stated, you've hardly made a case...except a 'special case' which is
> therefore, a logical fallacy.
>
>
>

I never said you shouldn't format SQL. I said the way you did it is stupid.

But like anyone with no argument, you keep trying to put words into my
mouth.

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

Re: mySQL Problem

"Jerry Stuckle" wrote in message
news:8YCdndIBAbkzsq7anZ2dnUVZ_hmtnZ2d@comcast.com...
> Steve wrote:
>> "Jerry Stuckle" wrote in message
>> news:192dnW2kIL6akq7anZ2dnUVZ_sjinZ2d@comcast.com...
>>> Steve wrote:
>>>> "The Natural Philosopher" wrote in message
>>>> news:1194484441.81272.6@demeter.uk.clara.net...
>>>>> Darko wrote:
>>>>>> On Nov 7, 10:37 pm, "Steve" wrote:
>>>>>>> "Darko" wrote in message
>>>>>>>
>>>>>>> news:1194463439.305946.20240@z9g2000hsf.googlegroups.com...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Nov 7, 6:19 pm, "Steve" wrote:
>>>>>>>>> well !!! lo-and-behold!!! when you get your error message back
>>>>>>>>> THIS time,
>>>>>>>>> you actually get a line number OTHER THAN 1 !!! now THAT would be
>>>>>>>>> helpful!
>>>>>>>>> imagine too, that you echo this out to the browser, copy it, and
>>>>>>>>> paste it
>>>>>>>>> directly into your mysql query browser...then execute it. even
>>>>>>>>> before
>>>>>>>>> then,
>>>>>>>>> you might have discovered (since you can now READ IT) that there
>>>>>>>>> is
>>>>>>>>> something wrong in the data you're inserting.
>>>>>>>> Having yelled that out, haven't you ever noticed that mysql (and so
>>>>>>>> do
>>>>>>>> other
>>>>>>>> sql servers) specify precisely where the problem is - this time it
>>>>>>>> said:
>>>>>>>>> near 'from, size, format, cat, host ...
>>>>>>> you obviously haven't written very long or complex queries. 'near'
>>>>>>> and ON
>>>>>>> LINE x are *worlds* apart, now aren't they.
>>>>>>>
>>>>>>>> ... so it was quite clear that it had had problem with "from".
>>>>>>> apparently not quite as clear to the op. :)
>>>>>>>
>>>>>>>> Considering php and
>>>>>>>> queries code readability you are, of course, right, since a
>>>>>>>> programmer
>>>>>>>> will much more
>>>>>>>> easily read the code formatted in the way you have, but considering
>>>>>>>> error information,
>>>>>>> you should ammend that...'considering the error information [IN THIS
>>>>>>> CASE]'.
>>>>>>>
>>>>>>> either way, it should be formatted as a rule...unless you're saying
>>>>>>> you can
>>>>>>> predict your errors, in which case you wouldn't make mistakes
>>>>>>> anyway.
>>>>>>>
>>>>>>>> sql servers are pretty precise about where the problem occurred,
>>>>>>>> code
>>>>>>>> being indented
>>>>>>>> or not.
>>>>>>> really? which ones? what is 'pretty' precise?
>>>>>>>
>>>>>>> the indenting is multipurpose. it is my experience that the top 4
>>>>>>> sql
>>>>>>> servers (ms sql, oracle, mysql, teradata) are generally *obtuse* in
>>>>>>> their
>>>>>>> error messages...but they all give line numbers!
>>>>>>>
>>>>>>>>> don't let me throw you on that one...bad data is NOT the problem
>>>>>>>>> here.
>>>>>>>>> there
>>>>>>>>> are things called RESERVED WORDS. one of those would be the word
>>>>>>>>> 'FROM'...as
>>>>>>>>> in "select * FROM". if you had correctly formatted your sql
>>>>>>>>> statement,
>>>>>>>>> the
>>>>>>>>> line number in error would have been line 6...a much better clue.
>>>>>>>> As for rude yelling about making mistakes with reserved words, that
>>>>>>>> is
>>>>>>>> something that happens
>>>>>>>> to many people, even experienced, from time to time, so no need to
>>>>>>>> get
>>>>>>>> upset about it.
>>>>>>> rude? lol.
>>>>>>>
>>>>>>> you even infer rudeness about the mistake itself. no, i capitalized
>>>>>>> FROM so
>>>>>>> that it stood out. if that hurt your ears, then you won't hear me
>>>>>>> laughing
>>>>>>> right now. my intention throughout the thread here has been to make
>>>>>>> a point
>>>>>>> about formatting. did you not notice that even though i told him
>>>>>>> what the
>>>>>>> problem was, i did not tell him how to fix it? hmmmm...must not have
>>>>>>> been
>>>>>>> the goal of my post. seems you've missed that point.
>>>>>>>
>>>>>>>> I once
>>>>>>>> named two variables in C like "od" and "do", and couldn't find out
>>>>>>>> what was wrong with it until
>>>>>>>> I realised it was the "do" keyword.
>>>>>>> christ almighty! i suppose you proliferate the use of variables like
>>>>>>> $tmp
>>>>>>> too. what a goof! 'do'? for the love of god, almost *every* language
>>>>>>> has a
>>>>>>> *do* loop construct. so, when you said, 'even experienced' above,
>>>>>>> you were
>>>>>>> not associating yourself among those. :)
>>>>>>>
>>>>>>>> Finally, it is not "reserved" word in any sql, as you can indeed
>>>>>>>> name
>>>>>>>> any field "from", as long
>>>>>>>> as you make the parser know it. For an example, this is totally
>>>>>>>> legal:
>>>>>>>> select name, img, descr, "from", size, format from table;
>>>>>>> why yes. now why would i NOT explain that to the op? must not have
>>>>>>> been the
>>>>>>> purpose of my post. what's more, i'd be encouraging BAD behavior. if
>>>>>>> you
>>>>>>> think that's just my ho, why don't you prepose that question in a db
>>>>>>> forum...bring your asbestos umbrella, cuz it'll rain fire from the
>>>>>>> first
>>>>>>> response to the last. dba's are kinda picky that way.
>>>>>>>
>>>>>>>> just as long as you keep the double quotes around key words.
>>>>>>> ahhhh...you assume too much. oracle will fart on your double quotes.
>>>>>>> it
>>>>>>> likes either single tics or single back tics (`). again, you just
>>>>>>> killed a
>>>>>>> great chance for scalability. you should be able to take your code
>>>>>>> base and
>>>>>>> plop it down in front of any db and nothing breaks. you've forced
>>>>>>> yourself
>>>>>>> to reprogram when switching from one db to another...which is the
>>>>>>> shits when
>>>>>>> you're prototyping on your local pc using mysql and pushing code to
>>>>>>> production where teradata is the db being used.
>>>>>>>
>>>>>>> wanna keep going, darko?
>>>>>> Yes, please.
>>>>>>
>>>>>> It wasn't my intention to encourage Einstein30000 to use such field
>>>>>> names as "from" or "select",
>>>>>> the idea was only that such errors happen even to experienced
>>>>>> programmers, not indicating whether
>>>>>> I consider myself one or not - it's pretty relative thing, as you
>>>>>> know.
>>>>>>
>>>>>> As for "od" and "do", you should first know that I am a Serb, and
>>>>>> that
>>>>>> in Serbian language "od" means "from",
>>>>>> and "do" means "to", so "od 1 do 10" means "from 1 to 10". Thus, once
>>>>>> in a simple C program I needed such "from" and
>>>>>> "to" helper variables, and I named them "od" and "do". It would have
>>>>>> been much easier to avoid if I was writing in
>>>>>> English, which I usually do when making non-test programs, since then
>>>>>> it would be easier to "hear" it as the English
>>>>>> do. But, being switched to Serbian in my mind, I didn't see any
>>>>>> danger
>>>>>> coming of it, and the
>>>>>> compiler was pretty vague about the error, as you know it can be, and
>>>>>> I hardly recognized it. This is,
>>>>>> if you'd really like to know.
>>>>>>
>>>>>> As for yelling, your uppercasing "FROM" explanation doesn't mention
>>>>>> the "your sql statement is F.U.C.K.E.D", "well !!! lo-and-behold!!!",
>>>>>> "a line number OTHER THAN 1 !!! now THAT would be helpful! ", "since
>>>>>> you can now READ IT", "bad data is NOT the problem here. there are
>>>>>> things called RESERVED WORDS. " statements, which I normally
>>>>>> considered yelling. It's just not polite to address people like that,
>>>>>> especially ones that came for advice and help.
>>>>>>
>>>>>> Regards,
>>>>>> Darko
>>>>>>
>>>>> I'm with darko here. It took me about 5 seconds flat to realise what
>>>>> was wrong.
>>>>>
>>>>>
>>>>>
>>>>> No need to blow it across 15 lines.
>>>>>
>>>>> Unless you are the sort person who can't count beyond ten without
>>>>> taking their socks off.
>>>>>
>>>>>
>>>>> Mysql barfs where its parser gets confused..that was at the word
>>>>> 'from' Simple.
>>>> right. and no one is arguing the simple nature of identifying the
>>>> problem here. however, it becomes very difficult, not only to read, but
>>>> to maintain and debug sql statements that are not well
>>>> formatted...which helps more quickly identify the root cause when it is
>>>> less than obvious.
>>>>
>>>> i'm not for or against anyone. i'm for a systemic approach that covers
>>>> all the bases and is a best practice. that's all. it has little to do
>>>> with the actual problem faced here with reserved words.
>>> Sorry, Steve - I don't agree with your method of "properly formatting"
>>> the SQL. It takes way too much space on the page. It is not "correct"
>>> by virtually any programmer I know.
>>
>> too much space? is there a premium on space in your editor, jerry? would
>> you like me to post a query i have for running financial statistics here?
>> i would be more than willing to un-format it so just a single line in
>> order to save 'virtual' space on the 'virtual' page if you'd like. :)
>>
>
> Don't be an asshole again, Steve. My editor isn't limited, but my screen
> size is, and that wastes a lot of it.

again? when was i being an asshole at all, jerry? i was sarcastically making
a point. one of which is that your screen realestate is far less expensive
than spending the time it takes to debug non-functioning
queries...especially when the query is more complex that what it seems
you've written in the course of your experience. you'd probably start by
*formatting* said query so you could break it down and isolate the problem.
after all of that's done, you probably would spend a fraction of time fixing
the actual problem. if it is formatted to begin with, you are less likely to
introduce problems, more able to expand a query, and very quickly able to
fix whatever else may ail it.

if it's that big of a deal, buy an editor with code folding.

again, am i an asshole simply because i have been calmly disagreeing with
you?


>> as far as being 'correct by virtually any programmer i [you] know'...that
>> may be as 'virtual' as the space such a query takes up. as for what is
>> reported, documented, and written about code formatting - inclusive of
>> sql - i think you're outnumbered.
>>
>
> Yep, programmers with any sense don't do it that way. The do it similar
> to:
>
> SELECT a,b,c
> FROM x
> WHERE y='z';
>
> Or something similar. And in the almost 25 years I've been doing SQL, I
> can probably count on two hands the number of experienced programmers who
> write SQL as you did. And hundreds who do it the way I learned.

you know what? me too. however, those handful are the ones from whom i
learned the most. they showed me that consistency, simplicity, and
manageability are the keys to not only good code, but a successful career.

also, in addition to being an asshole for disagreeing with you, jerry, i'm
now a programmer without any sense...and for simply the same reason?! rof.

i'm chuckling even more now though. don't you notice a difference between
the example you gave:

select a, b, c
from x
where y='z'

and the real formatting issue being discussed here...in the genre of:

select a, b, c from x where y='z'


hmmmm...the former being formatted in some way, the latter, not at all. and
i'm senseless?

let's take that example though a bit further and say we're dealing with php
code. if a function has parameters a, b, and c. you probably write it and
call it thusly:

function foo($a, $b, $c)
{
return true;
}

i bet though, that when your parameter names are very long and numerous, you
either single line them or column-ize them, like this:

function foo(
$a ,
$b ,
$c ,
...
)
{
return true;
}

and i bet you do the same when defining arrays, right? ask yourself why.
probably because it is more legible and maintainable, right? if the only
time you do this is when the function's params are way in the right margin,
forcing you to scroll to see them all...essencially screen space, i think
i'll but a gut.

>> for the same reasons you should format sql, you format any other language
>> you write in. i'm sure you've written lots of scripts that are over
>> several hundred lines. why would you approach writing sql any differently
>> than other language? just curious jerry. if you have no other explanation
>> than what you've stated, you've hardly made a case...except a 'special
>> case' which is therefore, a logical fallacy.
>
> I never said you shouldn't format SQL. I said the way you did it is
> stupid.

wow! i should have gotten 'stupid' from "I don't agree with your method..."?
i'm really going to have to read your posts with a lot more inferencing than
is normally due any other human being. that is, unless you are saying it is
stupid now...as opposed to "i said...".

likewise, rather than bash the way i format sql, wouldn't it have been more
helpful to address the point of FORMATTING sql - which was my point to begin
with. further, providing an example of the way YOU format sql would have
expanded the topic for the op. hell, i may even side with YOUR version of
formatting sql v. the way I format mine. but, simply leaving it at 'your way
is stupid, you're an asshole and senseless for disagreeing with me' doesn't
really help anyone...or, your cause - which i have yet to figure out here
yet.

> But like anyone with no argument, you keep trying to put words into my
> mouth.

wow jerry, i've been stating MY case. i've not even addressed any of your
points. look at your ONE, SINGLE POST in this thread. what POINT (much less
points, plural) did you actually make? you said you disagree with me. that's
fine. i simply added more reasons for you/anyone to understand why i and
others do things the way we do.

so please, quote me and the words you are proposing that i'm putting in your
mouth.

i hope you are not projecting on me here from some other thread where some
other person has bashed you. as you know, i have no beef with you. and
throughout this thread in rebuttal with you and darko, i've been unusually
polite. hence my puzzlement of being called an asshole, senseless, and
stupid. how did i get your ire up so?

Re: mySQL Problem

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

Re: mySQL Problem

Steve wrote:
> "lawrence k" wrote in message
> news:1194496438.926297.74650@o38g2000hse.googlegroups.com...
>> On Nov 7, 12:19 pm, "Steve" wrote:
>>> "Einstein30000" wrote in message
>>>
>>> news:1194453026.587359.180320@19g2000hsx.googlegroups.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.
>
>
The trouble with standards is here are som nay to choose from..



$query="select name, id from employees order by name";

Nowt wrong with that is there?

Now consider

$query =sprintf( "select name, id, number, picture, phone, email from
employees where id= (select employee_id date from sacked where name
like %s%% order by sacked.date )",$badboys);

and it starts to get messier..
You don't slavishly follow rules..unless you are a jerk, or working for
one.....

"Its is a company coding policy that any subroutine or multi-use stub of
code in assembler be preceded by a minimum 5 lines of header comment
describing what the function does and how it affects global variables if
any and a miniumum of a comment per 2 lines of code to describe waht is
being achived bty the lines"

FUNC_EXIT:
;*********************************************
;*This s a stub of code
;*it is here to save ROM space.
;*It simply takes one 3 byte JMP to replace 5 bytes of
;*instruction that every C compatible subroutine has in it
;*There you bastards thats your 5 lines.
;********************************************

MOV DX,SP ; restore stack to entry point
POP DX ; restore DX to previous frame pointer
POP CX
POP BX ; restore temp registers.
RET



;-)

Re: mySQL Problem

"The Natural Philosopher" wrote in message
news:1194542959.6724.0@proxy00.news.clara.net...
> Steve wrote:
>> "lawrence k" wrote in message
>> news:1194496438.926297.74650@o38g2000hse.googlegroups.com...
>>> On Nov 7, 12:19 pm, "Steve" wrote:
>>>> "Einstein30000" wrote in message
>>>>
>>>> news:1194453026.587359.180320@19g2000hsx.googlegroups.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.
> The trouble with standards is here are som nay to choose from..
>
>
>
> $query="select name, id from employees order by name";
>
> Nowt wrong with that is there?
>
> Now consider
>
> $query =sprintf( "select name, id, number, picture, phone, email from
> employees where id= (select employee_id date from sacked where name like
> %s%% order by sacked.date )",$badboys);
>
> and it starts to get messier..
> You don't slavishly follow rules..unless you are a jerk, or working for
> one.....

oh, so 'dont be a jerk'...is THAT how you make a point? ad-homonym all you'd
like. the rest of us set policy and are consistent about following it. draw
your messy grey lines where you will.

Re: mySQL Problem

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 '

' . print_r($sql, true) . '

Re: mySQL Problem

"Darko" wrote in message
news:1194548159.951566.11580@k35g2000prh.googlegroups.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 '

' . print_r($sql, true) . '

Re: mySQL Problem

Steve wrote:
> "Jerry Stuckle" wrote in message
>>> too much space? is there a premium on space in your editor, jerry? would
>>> you like me to post a query i have for running financial statistics here?
>>> i would be more than willing to un-format it so just a single line in
>>> order to save 'virtual' space on the 'virtual' page if you'd like. :)
>>>
>> Don't be an asshole again, Steve. My editor isn't limited, but my screen
>> size is, and that wastes a lot of it.
>
> again? when was i being an asshole at all, jerry? i was sarcastically making
> a point. one of which is that your screen realestate is far less expensive
> than spending the time it takes to debug non-functioning
> queries...especially when the query is more complex that what it seems
> you've written in the course of your experience. you'd probably start by
> *formatting* said query so you could break it down and isolate the problem.
> after all of that's done, you probably would spend a fraction of time fixing
> the actual problem. if it is formatted to begin with, you are less likely to
> introduce problems, more able to expand a query, and very quickly able to
> fix whatever else may ail it.
>

First of all, it didn't come through as sarcastic. If that is how it
was meant, then I apologize.

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.

And I didn't say don't format - you're putting words in my mouth. I
said your method of formatting is lousy.

> if it's that big of a deal, buy an editor with code folding.
>
> again, am i an asshole simply because i have been calmly disagreeing with
> you?
>

It's the way you disagreed.

>
>>> as far as being 'correct by virtually any programmer i [you] know'...that
>>> may be as 'virtual' as the space such a query takes up. as for what is
>>> reported, documented, and written about code formatting - inclusive of
>>> sql - i think you're outnumbered.
>>>
>> Yep, programmers with any sense don't do it that way. The do it similar
>> to:
>>
>> SELECT a,b,c
>> FROM x
>> WHERE y='z';
>>
>> Or something similar. And in the almost 25 years I've been doing SQL, I
>> can probably count on two hands the number of experienced programmers who
>> write SQL as you did. And hundreds who do it the way I learned.
>
> you know what? me too. however, those handful are the ones from whom i
> learned the most. they showed me that consistency, simplicity, and
> manageability are the keys to not only good code, but a successful career.
>

Sure. And what do you do when you have a recursive query with 50
different parameters from 5 joined tables with a half dozen conditions
(not including the joins)? I've had queries run upwards of 2K characters.

Let's see you format THOSE queries the way you espouse and get them on
in a single window in something larger than 1 point font.

> also, in addition to being an asshole for disagreeing with you, jerry, i'm
> now a programmer without any sense...and for simply the same reason?! rof.
>
> i'm chuckling even more now though. don't you notice a difference between
> the example you gave:
>
> select a, b, c
> from x
> where y='z'
>
> and the real formatting issue being discussed here...in the genre of:
>
> select a, b, c from x where y='z'
>

No, it's the difference between

select a, b, c
from x
where y='z'

and

select
a,
b,
c
from
d
where
y='z'

Now - which one is more readable?

>
> hmmmm...the former being formatted in some way, the latter, not at all. and
> i'm senseless?
>
> let's take that example though a bit further and say we're dealing with php
> code. if a function has parameters a, b, and c. you probably write it and
> call it thusly:
>
> function foo($a, $b, $c)
> {
> return true;
> }
>

No, I don't. I write it as

function foo($a, $b, $c) {
return true;
}

> i bet though, that when your parameter names are very long and numerous, you
> either single line them or column-ize them, like this:
>
> function foo(
> $a ,
> $b ,
> $c ,
> ...
> )
> {
> return true;
> }
>

Nope. If it all fits in one line on my screen, I put it on one line.
Otherwise I split it into 2 lines, with the second line indented, such as:

function foo ($a, $b, $c ..... lots more
$x, $y, $z) {
return true;
}

And BTW, if my SQL clause gets too long, I do it the same way.

> and i bet you do the same when defining arrays, right? ask yourself why.
> probably because it is more legible and maintainable, right? if the only
> time you do this is when the function's params are way in the right margin,
> forcing you to scroll to see them all...essencially screen space, i think
> i'll but a gut.
>

Nope. I do arrays similar to the rest.

>>> for the same reasons you should format sql, you format any other language
>>> you write in. i'm sure you've written lots of scripts that are over
>>> several hundred lines. why would you approach writing sql any differently
>>> than other language? just curious jerry. if you have no other explanation
>>> than what you've stated, you've hardly made a case...except a 'special
>>> case' which is therefore, a logical fallacy.
>> I never said you shouldn't format SQL. I said the way you did it is
>> stupid.
>
> wow! i should have gotten 'stupid' from "I don't agree with your method..."?
> i'm really going to have to read your posts with a lot more inferencing than
> is normally due any other human being. that is, unless you are saying it is
> stupid now...as opposed to "i said...".
>

Well, that's what I think about your formatting method. It wastes all
kinds of screen space, making it much harder to see the big picture.

> likewise, rather than bash the way i format sql, wouldn't it have been more
> helpful to address the point of FORMATTING sql - which was my point to begin
> with. further, providing an example of the way YOU format sql would have
> expanded the topic for the op. hell, i may even side with YOUR version of
> formatting sql v. the way I format mine. but, simply leaving it at 'your way
> is stupid, you're an asshole and senseless for disagreeing with me' doesn't
> really help anyone...or, your cause - which i have yet to figure out here
> yet.
>

I did address the point. And I did provide an example. But when you
promote poor formatting practices, I'll call you on it.

>> But like anyone with no argument, you keep trying to put words into my
>> mouth.
>
> wow jerry, i've been stating MY case. i've not even addressed any of your
> points. look at your ONE, SINGLE POST in this thread. what POINT (much less
> points, plural) did you actually make? you said you disagree with me. that's
> fine. i simply added more reasons for you/anyone to understand why i and
> others do things the way we do.
>
> so please, quote me and the words you are proposing that i'm putting in your
> mouth.
>

You stated that I advocated no formatting of the sql statements. That
is not what I said. Go back and read.

> i hope you are not projecting on me here from some other thread where some
> other person has bashed you. as you know, i have no beef with you. and
> throughout this thread in rebuttal with you and darko, i've been unusually
> polite. hence my puzzlement of being called an asshole, senseless, and
> stupid. how did i get your ire up so?
>
>
>

No, I'm addressing you and what you said.

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

Re: mySQL Problem

The Natural Philosopher wrote:
> Steve wrote:
>> "lawrence k" wrote in message
>> news:1194496438.926297.74650@o38g2000hse.googlegroups.com...
>>> On Nov 7, 12:19 pm, "Steve" wrote:
>>>> "Einstein30000" wrote in message
>>>>
>>>> news:1194453026.587359.180320@19g2000hsx.googlegroups.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.
>>
> The trouble with standards is here are som nay to choose from..
>
>
>
> $query="select name, id from employees order by name";
>
> Nowt wrong with that is there?
>
> Now consider
>
> $query =sprintf( "select name, id, number, picture, phone, email from
> employees where id= (select employee_id date from sacked where name
> like %s%% order by sacked.date )",$badboys);
>
> and it starts to get messier..
> You don't slavishly follow rules..unless you are a jerk, or working for
> one.....
>
> "Its is a company coding policy that any subroutine or multi-use stub of
> code in assembler be preceded by a minimum 5 lines of header comment
> describing what the function does and how it affects global variables if
> any and a miniumum of a comment per 2 lines of code to describe waht is
> being achived bty the lines"
>
> FUNC_EXIT:
> ;*********************************************
> ;*This s a stub of code
> ;*it is here to save ROM space.
> ;*It simply takes one 3 byte JMP to replace 5 bytes of
> ;*instruction that every C compatible subroutine has in it
> ;*There you bastards thats your 5 lines.
> ;********************************************
>
> MOV DX,SP ; restore stack to entry point
> POP DX ; restore DX to previous frame pointer
> POP CX
> POP BX ; restore temp registers.
> RET
>
>
>
> ;-)
>
>
>

I love it!

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

Re: mySQL Problem

"Jerry Stuckle" wrote in message
news:I8idnbCucsiO867anZ2dnUVZ_ournZ2d@comcast.com...
> Steve wrote:
>> "Jerry Stuckle" wrote in message
>>>> too much space? is there a premium on space in your editor, jerry?
>>>> would you like me to post a query i have for running financial
>>>> statistics here? i would be more than willing to un-format it so just a
>>>> single line in order to save 'virtual' space on the 'virtual' page if
>>>> you'd like. :)
>>>>
>>> Don't be an asshole again, Steve. My editor isn't limited, but my
>>> screen size is, and that wastes a lot of it.
>>
>> again? when was i being an asshole at all, jerry? i was sarcastically
>> making a point. one of which is that your screen realestate is far less
>> expensive than spending the time it takes to debug non-functioning
>> queries...especially when the query is more complex that what it seems
>> you've written in the course of your experience. you'd probably start by
>> *formatting* said query so you could break it down and isolate the
>> problem. after all of that's done, you probably would spend a fraction of
>> time fixing the actual problem. if it is formatted to begin with, you are
>> less likely to introduce problems, more able to expand a query, and very
>> quickly able to fix whatever else may ail it.
>>
>
> First of all, it didn't come through as sarcastic. If that is how it was
> meant, then I apologize.

that's fine.

> 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?!

> And I didn't say don't format - you're putting words in my mouth. I said
> your method of formatting is lousy.

well, first you said you didn't care for mine. then you said mine was
stupid. now it's just lousy...all the while missing the point that
FORMATTING is what was being discussed, not MY FORMATTING STYLE. i couldn't
care less about your thoughts on my style...just as you probably mirror in
my reflections on yours, or anyone else's for that matter.

if you stick to the point (formatting) then i'll be far less likely to
assume my 'method' you originally stated disagreement with means 'formatting
in general' instead of 'steve's particular formatting style'. and were that
the case, i'd have said 'i don't care how you feel about it, jerry'. as it
is, you went on a tangent while the rest of us were still talking about
*formatting* - regarless of styles.

>> if it's that big of a deal, buy an editor with code folding.
>>
>> again, am i an asshole simply because i have been calmly disagreeing with
>> you?
>>
>
> It's the way you disagreed.

he, he, he. calmly? come one jerry! you've seen enough of my posts to know
when i'm being an ass or tryin to be one. i think something just went wrong
for you today and your sensitive about something wholly unrelated.

>>>> as far as being 'correct by virtually any programmer i [you]
>>>> know'...that may be as 'virtual' as the space such a query takes up. as
>>>> for what is reported, documented, and written about code formatting -
>>>> inclusive of sql - i think you're outnumbered.
>>>>
>>> Yep, programmers with any sense don't do it that way. The do it similar
>>> to:
>>>
>>> SELECT a,b,c
>>> FROM x
>>> WHERE y='z';
>>>
>>> Or something similar. And in the almost 25 years I've been doing SQL, I
>>> can probably count on two hands the number of experienced programmers
>>> who write SQL as you did. And hundreds who do it the way I learned.
>>
>> you know what? me too. however, those handful are the ones from whom i
>> learned the most. they showed me that consistency, simplicity, and
>> manageability are the keys to not only good code, but a successful
>> career.
>>
>
> Sure. And what do you do when you have a recursive query with 50
> different parameters from 5 joined tables with a half dozen conditions
> (not including the joins)? I've had queries run upwards of 2K characters.

what? jerry, the larger and more complex a query, the MORE you need to
format it - indenting, aligning, etc.. i'm not sure i follow where you're
wanting to take this.

> Let's see you format THOSE queries the way you espouse and get them on in
> a single window in something larger than 1 point font.

you're putting the criteria on it, not me. i couldn't care less if it fit in
a single window or if it required multiple caches to cleanly scroll through
the whole thing.

are you telling me that it is best to leave queries unformatted, especially
the more complex in nature they become? either you're digging your own grave
here, or, you're still stuck on my particular style of code formatting. if
the latter, i could give a flying fuck. if the latter, there's no need to
continue the conversation, mainly because you have yet to address my one and
only point - format your fucking sql statements. and just for you jerry,
since you still can't catch on...i don't care how anyone stylistically
formats their sql in particular. to each their own on that issue. now let's
move on.

>> also, in addition to being an asshole for disagreeing with you, jerry,
>> i'm now a programmer without any sense...and for simply the same reason?!
>> rof.
>>
>> i'm chuckling even more now though. don't you notice a difference between
>> the example you gave:
>>
>> select a, b, c
>> from x
>> where y='z'
>>
>> and the real formatting issue being discussed here...in the genre of:
>>
>> select a, b, c from x where y='z'
>>
>
> No, it's the difference between
>
> select a, b, c
> from x
> where y='z'
>
> and
>
> select
> a,
> b,
> c
> from
> d
> where
> y='z'
>
> Now - which one is more readable?

in my opinion:

SELECT a ,
b ,
c
FROM d
WHERE y = 'z'

is most readable and manageable...esp. when i want to add new fields to the
query. i go to the select, hit enter, drop the new field in. if it's all
listed, i'm just adding to a pool. ever have a problem of selecting the same
field twice in the same query? i never have. i can clearly see what fields
i'm working with. notice that i even align my commas and keep them
measurably out of the way of the field list so as not to disturb my view?
and yes, i even align my equations so i get a list of things and how each
relates to some other thing (i.e. y = 'z', etc.).

again though, this is your tangent...not mine. as far as your stylistic
practices or mine, i don't care. formatting v. not formatting. keep
repeating that to yourself jerry. enough times so that it will eventually
sink in that that was my point. then you'll quit arguing over non-sense.

>> hmmmm...the former being formatted in some way, the latter, not at all.
>> and i'm senseless?
>>
>> let's take that example though a bit further and say we're dealing with
>> php code. if a function has parameters a, b, and c. you probably write it
>> and call it thusly:
>>
>> function foo($a, $b, $c)
>> {
>> return true;
>> }
>>
>
> No, I don't. I write it as
>
> function foo($a, $b, $c) {
> return true;
> }
>
>> i bet though, that when your parameter names are very long and numerous,
>> you either single line them or column-ize them, like this:
>>
>> function foo(
>> $a ,
>> $b ,
>> $c ,
>> ...
>> )
>> {
>> return true;
>> }
>>
>
> Nope. If it all fits in one line on my screen, I put it on one line.

about to bust a gut...gotta hold it in...

> Otherwise I split it into 2 lines, with the second line indented, such as:

WELL HOLY SHIT !!! so you COLUMN-IZE !!! did i not mention that? again, if
screen realestate is your only concern here, then why bother to write php in
any other fashion. it parses the same as sql - spaces stripped and so on?
just one line the whole thing. oh yeah, you DO format...you just don't care
for how I format. not my point or a concern of mine, jerry. argue that till
you're blue in the face. in the end, it's a stylistic issue and to each
their own. just like how you put the body brace on the same line as the
ending parenth of the function rather than on it's own line. :)

i'm not arguing style. again i say, repeat that to yourself until it sinks
in.

> function foo ($a, $b, $c ..... lots more
> $x, $y, $z) {
> return true;
> }
>
> And BTW, if my SQL clause gets too long, I do it the same way.

imagine that!

>> and i bet you do the same when defining arrays, right? ask yourself why.
>> probably because it is more legible and maintainable, right? if the only
>> time you do this is when the function's params are way in the right
>> margin, forcing you to scroll to see them all...essencially screen space,
>> i think i'll but a gut.
>>
>
> Nope. I do arrays similar to the rest.

'nope'? 'similar to the rest'? so, 'nope' is really 'yep' since i suggested
both one-lining params *and* columnizing them...just as you explained you do
in your example above. are you just being disagreeable today? at least
disagree with me! not agreeing with yourself, aside from looking silly, just
isn't profitable for you.

>>>> for the same reasons you should format sql, you format any other
>>>> language you write in. i'm sure you've written lots of scripts that are
>>>> over several hundred lines. why would you approach writing sql any
>>>> differently than other language? just curious jerry. if you have no
>>>> other explanation than what you've stated, you've hardly made a
>>>> case...except a 'special case' which is therefore, a logical fallacy.
>>> I never said you shouldn't format SQL. I said the way you did it is
>>> stupid.
>>
>> wow! i should have gotten 'stupid' from "I don't agree with your
>> method..."? i'm really going to have to read your posts with a lot more
>> inferencing than is normally due any other human being. that is, unless
>> you are saying it is stupid now...as opposed to "i said...".
>>
>
> Well, that's what I think about your formatting method. It wastes all
> kinds of screen space, making it much harder to see the big picture.

hmmm, i've never heard that about my queries before. quite the opposite. as
i'm not averse to screen space usage, it's not a big deal to me. further,
were it, i'd use a code folding editor.

as it is, i couldn't give two rats asses whether you approve of my
formatting. that is NOT what i've been discussing. do you get that yet?

>> likewise, rather than bash the way i format sql, wouldn't it have been
>> more helpful to address the point of FORMATTING sql - which was my point
>> to begin with. further, providing an example of the way YOU format sql
>> would have expanded the topic for the op. hell, i may even side with YOUR
>> version of formatting sql v. the way I format mine. but, simply leaving
>> it at 'your way is stupid, you're an asshole and senseless for
>> disagreeing with me' doesn't really help anyone...or, your cause - which
>> i have yet to figure out here yet.
>>
>
> I did address the point.

no, your point was that you disagree with my method. that could be
formatting or style. since you can't grasp that my point was formatting, it
is easy for you to think you've addressed the point. the only time you
actually glanced the point was when you said you do encourage formatted sql.
fine, discussion over. we agree. as to style? i don't care.

> And I did provide an example. But when you promote poor formatting
> practices, I'll call you on it.

poor in the eyes of jerry stuckle. you objection is saying that it takes up
too much screen space. i've added many descriptives of individual benefits
to my stylization/formatting. you have yet to counter any single one of
them. there's a good debate were you to do so. name calling and slander
('promote poor formatting practices') without a cite to back up the premise
is hardly an engagement at all. are you going to 'recurse' or are you going
to counter? i'm not interested in your current vein...a non-opinionated,
supported counter would be nice about now.

call me on it with fact, jerry. if i want to entagle myself in a stylistic
debate, fact will be my only lure. as it is, we agree on the value of
formatting sql statements. that was my point in all of my responses. get
over it.

>>> But like anyone with no argument, you keep trying to put words into my
>>> mouth.
>>
>> wow jerry, i've been stating MY case. i've not even addressed any of your
>> points. look at your ONE, SINGLE POST in this thread. what POINT (much
>> less points, plural) did you actually make? you said you disagree with
>> me. that's fine. i simply added more reasons for you/anyone to understand
>> why i and others do things the way we do.
>>
>> so please, quote me and the words you are proposing that i'm putting in
>> your mouth.
>>
>
> You stated that I advocated no formatting of the sql statements. That is
> not what I said. Go back and read.

i did.

topic == formatting sql NOT how STEVE formats sql. since the topic was
countered by you originally as 'i don't approve of your method of
formatting', it is logical that that sentence looks incomplete...completed
with 'sql statements'. that means to me, you don't advocate formatting sql.
otherwise, i'd just have said i don't care if anyone approves of how i do
it, just that it is done. and that would have been the end of the
discussion.

you've since described my formatting style as senseless, stupid, and lousy.
good on you! i couldn't care less...nor does anyone else here. at least
those adjectives alerted me to the fact that you didn't get my point, or
didn't want to acknowlege it - formatting sql == good.

>> i hope you are not projecting on me here from some other thread where
>> some other person has bashed you. as you know, i have no beef with you.
>> and throughout this thread in rebuttal with you and darko, i've been
>> unusually polite. hence my puzzlement of being called an asshole,
>> senseless, and stupid. how did i get your ire up so?
>
> No, I'm addressing you and what you said.

not very well. you glanced over my whole point in a frenzy of 'your way of
formatting sql statements blows...but oh yeah, formatting sql is in fact a
good thing to do'. where everything after the elipses is about
font-size:6.25...and subscript at that! formatting sql statements, jerry.
repeat it, rinse, then repeat it again. that's my point. any other tangent
you've brought forth is not a concern of mine as it all revolves around
opinion and stylistic tastes...unless again, you can give cites - however,
you don't seem to want to actually debate...just toss ad-homonyms about.

whatever.

Re: mySQL Problem

Steve wrote:
> "Jerry Stuckle" wrote in message



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

Re: mySQL Problem

"Jerry Stuckle" wrote in message
news:jeydnSVWVuqcFa7anZ2dnUVZ_u3inZ2d@comcast.com...
> Steve wrote:
>> "Jerry Stuckle" wrote in message
>
>


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: <8YCdndIBAbkzsq7anZ2dnUVZ_hmtnZ2d@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.

Re: mySQL Problem

On Nov 8, 11:20 pm, "Steve" wrote:
> "Jerry Stuckle" wrote in message
>
> news:jeydnSVWVuqcFa7anZ2dnUVZ_u3inZ2d@comcast.com...
>
> > Steve wrote:
> >> "Jerry Stuckle" wrote in message
>
> >
>
> 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: <8YCdndIBAbkzsq7anZ2dnUVZ_hmtnZ2d@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

Re: mySQL Problem

"Darko" wrote in message
news:1194571229.350686.153590@q5g2000prf.googlegroups.com...
> On Nov 8, 11:20 pm, "Steve" wrote:
>> "Jerry Stuckle" wrote in message
>>
>> news:jeydnSVWVuqcFa7anZ2dnUVZ_u3inZ2d@comcast.com...
>>
>> > Steve wrote:
>> >> "Jerry Stuckle" wrote in message
>>
>> >
>>
>> 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: <8YCdndIBAbkzsq7anZ2dnUVZ_hmtnZ2d@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.

Re: mySQL Problem

On Nov 8, 4:35 pm, "Steve" wrote:
> "Jerry Stuckle" wrote in message
>
> news:I8idnbCucsiO867anZ2dnUVZ_ournZ2d@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.

Re: mySQL Problem

"lawrence k" wrote in message
news:1194578158.074482.123910@t8g2000prg.googlegroups.com...
> On Nov 8, 4:35 pm, "Steve" wrote:
>> "Jerry Stuckle" wrote in message
>>
>> news:I8idnbCucsiO867anZ2dnUVZ_ournZ2d@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?

Re: mySQL Problem

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" wrote in message
>>> news:1194453026.587359.180320@19g2000hsx.googlegroups.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

Re: mySQL Problem

"AnrDaemon" wrote in message
news:247167785.20071109125445@freemail.ru...
> 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" wrote in message
>>>> news:1194453026.587359.180320@19g2000hsx.googlegroups.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?

ask a dba in a db usenet group...or one at your company. :)

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

no, it's an alias for an object really. but, yes, you can name it whatever
you wish. there is plenty of documentation in *every* db about avoiding such
conventions, esp. reserved words as dbo names, like the plague.

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

so, you admit that mssql uses something DIFFERENT and PARTICULAR to alias?
you realize that your code becomes TIED to that db until you rewrite every
query to fit the NEXT db you want to use, don't you?

> And I have no doubt that other server have identical solution for field
> names.

no, only a reliable few share the same notation...and even fewer of those
are among the most commonly used dbs. next!

> I think You are wrong and lack of proper quotation in field names isan
> extension, not the quotation.

no, jerry is right. what you think is unimportant in light of what can be
cited and proven as correct...which we certainly can here in this case.

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

cheers

Re: mySQL Problem

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" wrote in message
>>>> news:1194453026.587359.180320@19g2000hsx.googlegroups.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.
jstucklex@attglobal.net
==================

Re: mySQL Problem

Greetings, Steve.
In reply to Your message dated Friday, November 9, 2007, 13:05:21,

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

> no, it's an alias for an object really. but, yes, you can name it whatever
> you wish. there is plenty of documentation in *every* db about avoiding such
> conventions, esp. reserved words as dbo names, like the plague.

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

> so, you admit that mssql uses something DIFFERENT and PARTICULAR to alias?
> you realize that your code becomes TIED to that db until you rewrite every
> query to fit the NEXT db you want to use, don't you?

MS SQL uses different addressing schema anyway.
I always keep query sting templates in separate file, like localization
templates.
And I store them as constants to avoid modification at the time of script
execution.
So moving to different database is not a great issue. Smaller than
localization process.


--
Sincerely Yours, AnrDaemon

Re: mySQL Problem

AnrDaemon wrote:
> Greetings, Steve.
> In reply to Your message dated Friday, November 9, 2007, 13:05:21,
>
>>> 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.
>
>> no, it's an alias for an object really. but, yes, you can name it whatever
>> you wish. there is plenty of documentation in *every* db about avoiding such
>> conventions, esp. reserved words as dbo names, like the plague.
>
>>>> 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.
>
>> so, you admit that mssql uses something DIFFERENT and PARTICULAR to alias?
>> you realize that your code becomes TIED to that db until you rewrite every
>> query to fit the NEXT db you want to use, don't you?
>
> MS SQL uses different addressing schema anyway.
> I always keep query sting templates in separate file, like localization
> templates.
> And I store them as constants to avoid modification at the time of script
> execution.
> So moving to different database is not a great issue. Smaller than
> localization process.
>
>

Why complicate things by putting SQL statements in a different file
where you can't see them? 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.

There has been nothing in this thread which is non-ANSWI SQL - except
for the use of a reserved word in a column name.

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

Re: mySQL Problem

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

Re: mySQL Problem

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

Re: mySQL Problem

Post removed (X-No-Archive: yes)

Re: mySQL Problem

"AnrDaemon" wrote in message
news:763926623.20071112003911@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.

Re: mySQL Problem

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