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

Error in INSERT

P: n/a
I have a page that inserts these values in the table...

$fundo_nome = $_POST['fundo_nome'];
$fundo_link = $_POST['fundo_link'];
$fundo_activo = $_POST['fundo_activo'];

$sql = sprintf("INSERT INTO relatorio_fundo(fundo_nome,
fundo_link, fundo_activo) VALUES (%s, %s, %s)",
mysql_real_escape_string($fundo_nome),
mysql_real_escape_string($fundo_link),
mysql_real_escape_string($fundo_activo));
THen the error appears...:

Invalid query: 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 ' , )' at line 1
Can anyone help???
Jun 27 '08 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Pépê wrote:
Invalid query: 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 ' , )' at line 1
Enclose any string literals in your SQL query in quotes, and (as this is a
SQL question), ask in a SQL or DB newsgroup, not a PHP newsgroup.

--
----------------------------------
Iván Sánchez Ortega -ivansanchez-algarroba-escomposlinux-punto-org-

Un ordenador no es un televisor ni un microondas, es una herramienta
compleja.
Jun 27 '08 #2

P: n/a
Peter H. Coffin wrote:
On Tue, 24 Jun 2008 09:41:29 -0700 (PDT), Pp wrote:
>I have a page that inserts these values in the table...

$fundo_nome = $_POST['fundo_nome'];
$fundo_link = $_POST['fundo_link'];
$fundo_activo = $_POST['fundo_activo'];

$sql = sprintf("INSERT INTO relatorio_fundo(fundo_nome,
fundo_link, fundo_activo) VALUES (%s, %s, %s)",
mysql_real_escape_string($fundo_nome),
mysql_real_escape_string($fundo_link),
mysql_real_escape_string($fundo_activo));
THen the error appears...:

Invalid query: 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 ' , )' at line 1

It's ultimately going to be a comp.databases.mysql question instead,
but the FIRST debugging step for this kind of problem is to print out
what's in $sql before you run the query. If the answer isn't obvious
from looking at the query, ask on the other newsgroup, showing the
contents of $sql.
This seems like a lot of work and it's still susceptible to a stray
single quote.

What possible advantage does this coding style have over the simpler
PDO with prepare and placeholders?

Jeff
Jun 27 '08 #3

P: n/a
On Tue, 24 Jun 2008 14:38:19 -0400, Jeff wrote:
Peter H. Coffin wrote:
>On Tue, 24 Jun 2008 09:41:29 -0700 (PDT), Pp wrote:
[...]
It's ultimately going to be a comp.databases.mysql question instead,
but the FIRST debugging step for this kind of problem is to print out
what's in $sql before you run the query. If the answer isn't obvious
from looking at the query, ask on the other newsgroup, showing the
contents of $sql.
This seems like a lot of work and it's still susceptible to a stray
single quote.

What possible advantage does this coding style have over the simpler
PDO with prepare and placeholders?
Pointing at the wrong post before following up? (:

print $sql;

doesn't seem too complicated...

--
60. My five-year-old child advisor will also be asked to decipher any code I
am thinking of using. If he breaks the code in under 30 seconds, it will
not be used. Note: this also applies to passwords.
--Peter Anspach's list of things to do as an Evil Overlord
Jun 27 '08 #4

P: n/a
Jeff wrote:
Peter H. Coffin wrote:
>On Tue, 24 Jun 2008 09:41:29 -0700 (PDT), Pp wrote:
>>I have a page that inserts these values in the table...

$fundo_nome = $_POST['fundo_nome'];
$fundo_link = $_POST['fundo_link'];
$fundo_activo = $_POST['fundo_activo'];

$sql = sprintf("INSERT INTO
relatorio_fundo(fundo_nome,
fundo_link, fundo_activo) VALUES (%s, %s, %s)",
mysql_real_escape_string($fundo_nome),
mysql_real_escape_string($fundo_link),
mysql_real_escape_string($fundo_activo));
THen the error appears...:

Invalid query: 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 ' , )' at line 1

It's ultimately going to be a comp.databases.mysql question instead,
but the FIRST debugging step for this kind of problem is to print out
what's in $sql before you run the query. If the answer isn't obvious
from looking at the query, ask on the other newsgroup, showing the
contents of $sql.
This seems like a lot of work and it's still susceptible to a stray
single quote.

What possible advantage does this coding style have over the simpler
PDO with prepare and placeholders?

Jeff
Performance, among other things.

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

Jun 27 '08 #5

P: n/a
Jerry Stuckle wrote:
Jeff wrote:
>Peter H. Coffin wrote:
>>On Tue, 24 Jun 2008 09:41:29 -0700 (PDT), Pp wrote:
I have a page that inserts these values in the table...

$fundo_nome = $_POST['fundo_nome'];
$fundo_link = $_POST['fundo_link'];
$fundo_activo = $_POST['fundo_activo'];

$sql = sprintf("INSERT INTO
relatorio_fundo(fundo_nome,
fundo_link, fundo_activo) VALUES (%s, %s, %s)",
mysql_real_escape_string($fundo_nome),
mysql_real_escape_string($fundo_link),
mysql_real_escape_string($fundo_activo));
THen the error appears...:

Invalid query: 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 ' , )' at line 1

It's ultimately going to be a comp.databases.mysql question instead,
but the FIRST debugging step for this kind of problem is to print out
what's in $sql before you run the query. If the answer isn't obvious
from looking at the query, ask on the other newsgroup, showing the
contents of $sql.
This seems like a lot of work and it's still susceptible to a stray
single quote.

What possible advantage does this coding style have over the simpler
PDO with prepare and placeholders?

Jeff

Performance, among other things.
I've just done some reading and I've seen that (performance)
mentioned. That surprises me that the abstraction layer would take so
much...

There seems to be some rap about prepare. I would have thought that
preparing once and executing 10 times would be advantageous over
calling: mysql_query 10 times (for different values). What do I know,
though...

What other things are there? I haven't written so much PHP that I could
not change the way I process data.

Jeff
Jun 27 '08 #6

P: n/a
Jeff wrote:
Jerry Stuckle wrote:
>Jeff wrote:
>>Peter H. Coffin wrote:
On Tue, 24 Jun 2008 09:41:29 -0700 (PDT), Pp wrote:
I have a page that inserts these values in the table...
>
$fundo_nome = $_POST['fundo_nome'];
$fundo_link = $_POST['fundo_link'];
$fundo_activo = $_POST['fundo_activo'];
>
$sql = sprintf("INSERT INTO
relatorio_fundo(fundo_nome,
fundo_link, fundo_activo) VALUES (%s, %s, %s)",
mysql_real_escape_string($fundo_nome),
mysql_real_escape_string($fundo_link),
mysql_real_escape_string($fundo_activo));
>
>
THen the error appears...:
>
Invalid query: 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 ' , )' at line 1

It's ultimately going to be a comp.databases.mysql question instead,
but the FIRST debugging step for this kind of problem is to print out
what's in $sql before you run the query. If the answer isn't obvious
from looking at the query, ask on the other newsgroup, showing the
contents of $sql.

This seems like a lot of work and it's still susceptible to a stray
single quote.

What possible advantage does this coding style have over the simpler
PDO with prepare and placeholders?

Jeff

Performance, among other things.
I've just done some reading and I've seen that (performance) mentioned.
That surprises me that the abstraction layer would take so much...

There seems to be some rap about prepare. I would have thought that
preparing once and executing 10 times would be advantageous over
calling: mysql_query 10 times (for different values). What do I know,
though...

What other things are there? I haven't written so much PHP that I could
not change the way I process data.

Jeff
The system still has to call mysql_query or the equivalent sooner or
later. Yes, preparing once and calling multiple times with different
bound values can be faster - but you also have to add in the time
required to bind each variable. And how often in a single run of a
website script do you do that? I know I don't - I get all the
information I need the first time.

I'm not saying there are no uses for PDO. It's a good interface. But,
like everything, it is not applicable for every instance.

Personally, I don't use it - not due to performance reasons, but because
I like to have a little better control over what's going on.

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

Jun 27 '08 #7

P: n/a
On Tue, 24 Jun 2008 22:08:52 -0400, Jerry Stuckle wrote:
The system still has to call mysql_query or the equivalent sooner or
later. Yes, preparing once and calling multiple times with different
bound values can be faster - but you also have to add in the time
required to bind each variable. And how often in a single run of a
website script do you do that? I know I don't - I get all the
information I need the first time.
IMHE, the point in PHP/mysql where you start running into prepare/bind
being faster than assembling individual queries is someplace in the 100s
of operations. It's not usually worth the trouble for anything other
than writing custom loader applications.
Personally, I don't use it - not due to performance reasons, but because
I like to have a little better control over what's going on.
Being able to echo out a failing query WITH the values plugged in often
does save a lot of debugging time.... Sometimes a "syntax error" is
actually a data error.

--
It is impossible to sharpen a pencil with a blunt axe. It is equally vain
to try to do it with ten blunt axes instead -- E.W Dijkstra, 1930-2002
Jun 27 '08 #8

P: n/a
Jerry Stuckle wrote:
Jeff wrote:
>Jerry Stuckle wrote:
>>Jeff wrote:
Peter H. Coffin wrote:
On Tue, 24 Jun 2008 09:41:29 -0700 (PDT), Pp wrote:
<snip>
>>>
Performance, among other things.
I've just done some reading and I've seen that (performance)
mentioned. That surprises me that the abstraction layer would take so
much...

There seems to be some rap about prepare. I would have thought that
preparing once and executing 10 times would be advantageous over
calling: mysql_query 10 times (for different values). What do I know,
though...

What other things are there? I haven't written so much PHP that I
could not change the way I process data.

Jeff

The system still has to call mysql_query or the equivalent sooner or
later. Yes, preparing once and calling multiple times with different
bound values can be faster - but you also have to add in the time
required to bind each variable. And how often in a single run of a
website script do you do that? I know I don't - I get all the
information I need the first time.
I think you are better than I am at writing complex joins. It's
easier for me to just fish out linked data by another query.
Particularly when you have several rows coming back, that is easier (for
me).
>
I'm not saying there are no uses for PDO. It's a good interface. But,
like everything, it is not applicable for every instance.
I think you are right. I think I'll keep the housekeeping (backend)
stuff in PDO as I understand it well, and move the production stuff off.

I see Peter's point on this.

It looks like the sprintf/mysql_real_escape_string is probably a
reasonable way to go.
>
Personally, I don't use it - not due to performance reasons, but because
I like to have a little better control over what's going on.
What are you using? How do you check data?

More and more I think associative arrays (a perl hash) for
storing/moving data. The data has it's own crude name space and you can
process every item in the array in one function. Well I could if my php
had advanced to learning php references, I'm hashing my way through
TinyMCE at at the moment...

perhaps:

function cleanHash(&$insert_data){
foreach($insert_data as $key =$val){
$insert_data[$key] = mysql_real_escape_string($insert_data[$key]);
}
}

cleanHash(array('insert_1'=>'value_1',...));

I'm sure that isn't quite right... I suspect I need another reference.

Jeff
>
Jun 27 '08 #9

P: n/a
..oO(Peter H. Coffin)
>On Tue, 24 Jun 2008 22:08:52 -0400, Jerry Stuckle wrote:
>The system still has to call mysql_query or the equivalent sooner or
later. Yes, preparing once and calling multiple times with different
bound values can be faster - but you also have to add in the time
required to bind each variable. And how often in a single run of a
website script do you do that? I know I don't - I get all the
information I need the first time.

IMHE, the point in PHP/mysql where you start running into prepare/bind
being faster than assembling individual queries is someplace in the 100s
of operations. It's not usually worth the trouble for anything other
than writing custom loader applications.
In this case I don't care that much about performance. Both APIs call
native DB functions if possible. The main reason for me to use PDO is
simply convenience. I don't have to care about escaping or quoting, I
just pass my values to the DB and say how they should be treated, the DB
does the rest. Can't get any easier.
>Personally, I don't use it - not due to performance reasons, but because
I like to have a little better control over what's going on.

Being able to echo out a failing query WITH the values plugged in often
does save a lot of debugging time.... Sometimes a "syntax error" is
actually a data error.
Agreed, but it's not that difficult to do that with PDO either if you
need it. You can easily write a wrapper class around PDO and extend its
functionality.

Micha
Jun 27 '08 #10

This discussion thread is closed

Replies have been disabled for this discussion.