Select record by ID
11 answers - 1670 bytes -

I took the quotes off. I thought that quotes around numbers was wrong also.
I added the error checking and this is the error:
Could not perform 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
and this is the code again:
<?php
include("db.php");
$result = mysql_query("SELECT * FRM inf_member WHERE
user_id=$user_id");
if ( ! $result ) {
die ("Could not perform query $query: ".mysql_error()."\n");
}
while($myrow = mysql_fetch_assoc($result))
{
echo "<b>";
echo $myrow['user_name'];
echo "</b>";
echo $myrow['rank'];
echo "</b>";
echo $myrow['country'];
echo "</b>";
echo $myrow['email'];
echo "</b>";
echo $myrow['quote'];
echo "</b>";
echo $myrow['config'];
echo "</b>";
echo $myrow['map'];
echo "</b>";
echo $myrow['gun'];
echo "</b>";
echo $myrow['brand'];
echo "</b>";
echo $myrow['cpu'];
echo "</b>";
echo $myrow['ram'];
echo "</b>";
echo $myrow['video'];
echo "</b>";
echo $myrow['sound'];
echo "</b>";
echo $myrow['monitor'];
echo "</b>";
echo $myrow['mouse'];
echo "</b>";
echo $myrow['brand'];
echo "</b>";
}
?>
Laugh, share and connect with Windows Live Messenger
No.1 | | 2211 bytes |
| 
dom, 2007-01-28 at 18:51 -0500, nitrox . wrote:
I took the quotes off. I thought that quotes around numbers was wrong also.
Quotes are no necessary around numeric values, but they aren't wrong
neither, simply optional.
I added the error checking and this is the error:
Could not perform 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
Try with the new code I sent you too see the query you're sending,
probably -but not sure- $user_id is void and you're doing:
SELECT * FRM inf_member WHERE user_id=
Anyway if you can see the query, you'll see the source of the error.
and this is the code again:
<?php
include("db.php");
$result = mysql_query("SELECT * FRM inf_member WHERE
user_id=$user_id");
if ( ! $result ) {
die ("Could not perform query $query: ".mysql_error()."\n");
}
while($myrow = mysql_fetch_assoc($result))
{
echo "<b>";
echo $myrow['user_name'];
echo "</b>";
echo $myrow['rank'];
echo "</b>";
echo $myrow['country'];
echo "</b>";
echo $myrow['email'];
echo "</b>";
echo $myrow['quote'];
echo "</b>";
echo $myrow['config'];
echo "</b>";
echo $myrow['map'];
echo "</b>";
echo $myrow['gun'];
echo "</b>";
echo $myrow['brand'];
echo "</b>";
echo $myrow['cpu'];
echo "</b>";
echo $myrow['ram'];
echo "</b>";
echo $myrow['video'];
echo "</b>";
echo $myrow['sound'];
echo "</b>";
echo $myrow['monitor'];
echo "</b>";
echo $myrow['mouse'];
echo "</b>";
echo $myrow['brand'];
echo "</b>";
}
?>
Laugh, share and connect with Windows Live Messenger
PGP SIGNATURE
Version: GnuPG v1.4.3 (GNU/Linux)
eg4XPhb6hIX5m7zXiW4HacM=
=45oQ
PGP SIGNATURE
No.2 | | 455 bytes |
| 
Sunday 28 January 2007 5:54 pm, Francisco M. Marzoa Alonso wrote:
dom, 2007-01-28 at 18:51 -0500, nitrox . wrote:
I took the quotes off. I thought that quotes around numbers was wrong
also.
Quotes are no necessary around numeric values, but they aren't wrong
neither, simply optional.
Actually, I believe they are wrong in some database engines but not others.
MySQL doesn't care. Some others do. Yes, it sucks. :-(
No.3 | | 772 bytes |
| 
dom, 2007-01-28 at 18:20 -0600, Larry Garfield wrote:
Sunday 28 January 2007 5:54 pm, Francisco M. Marzoa Alonso wrote:
dom, 2007-01-28 at 18:51 -0500, nitrox . wrote:
I took the quotes off. I thought that quotes around numbers was wrong
also.
Quotes are no necessary around numeric values, but they aren't wrong
neither, simply optional.
Actually, I believe they are wrong in some database engines but not others.
MySQL doesn't care. Some others do. Yes, it sucks. :-(
Good point, but he's using mysql in this case, and in mysql they're
simply optional but not wrong.
Regards,
PGP SIGNATURE
Version: GnuPG v1.4.3 (GNU/Linux)
/ZWtZSx3mPPaLA+Mwh6I8=
=xG
PGP SIGNATURE
No.4 | | 1074 bytes |
| 
As someone else already stated, my best guess according to that error
is that $user_id has a null, or inappropriate value. The error occurs
at the last character of the query, so it has to be something like
hat. Echo the query and let us know what it outputs.
- Craige
1/28/07, Francisco M. Marzoa Alonso <francisco (AT) marzoa (DOT) comwrote:
dom, 2007-01-28 at 18:20 -0600, Larry Garfield wrote:
Sunday 28 January 2007 5:54 pm, Francisco M. Marzoa Alonso wrote:
dom, 2007-01-28 at 18:51 -0500, nitrox . wrote:
I took the quotes off. I thought that quotes around numbers was wrong
also.
Quotes are no necessary around numeric values, but they aren't wrong
neither, simply optional.
Actually, I believe they are wrong in some database engines but not others.
MySQL doesn't care. Some others do. Yes, it sucks. :-(
Good point, but he's using mysql in this case, and in mysql they're
simply optional but not wrong.
Regards,
>
>
>
>
No.5 | | 847 bytes |
| 
Sun, 2007-01-28 at 21:12 -0500, Craige Leeder wrote:
As someone else already stated, my best guess according to that error
is that $user_id has a null, or inappropriate value. The error occurs
at the last character of the query, so it has to be something like
hat. Echo the query and let us know what it outputs.
This is coding 101, echo your output and don't presume you know what
you're doing. My wager is that there's a 100% chance he has a null or
empty string value in the variable. A two second echo would have
presented the problem immediately. Given that he probably doesn't have a
clue what's in the variable, it's probably registered via register
globals or pulled directly from $_GET or $_PST and he's asking for
trouble by not escaping it.
Cheers,
Rob.
No.6 | | 1128 bytes |
| 
January 28, 2007 6:20 pm, Larry Garfield wrote:
Sunday 28 January 2007 5:54 pm, Francisco M. Marzoa Alonso wrote:
>dom, 2007-01-28 at 18:51 -0500, nitrox . wrote:
>I took the quotes off. I thought that quotes around numbers was
>wrong
>also.
>>
>Quotes are no necessary around numeric values, but they aren't wrong
>neither, simply optional.
>
Actually, I believe they are wrong in some database engines but not
others.
MySQL doesn't care. Some others do. Yes, it sucks. :-(
I believe it is now possible to *make* MySQL care by putting it into
"strict" mode when you start it
MySQL is the *only* db engine that lets you get away with [bleep] like
apostrophes around numbers.
I think strict mode also stops MySQL from the annoying habit of
silently converting inadmissable date/time to '0000-00-00' [grrrr]
It may even be possible to turn on strict mode with a query, and not
just from launch
http://dev.mysql.com/ would tell you more about this.
No.7 | | 655 bytes |
| 
Sun, January 28, 2007 6:20 pm, Larry Garfield wrote:
Sunday 28 January 2007 5:54 pm, Francisco M. Marzoa Alonso wrote:
>dom, 2007-01-28 at 18:51 -0500, nitrox . wrote:
>I took the quotes off. I thought that quotes around numbers was
>wrong
>also.
>>
>Quotes are no necessary around numeric values, but they aren't wrong
>neither, simply optional.
>
Actually, I believe they are wrong in some database engines but not
others.
MySQL doesn't care. Some others do. Yes, it sucks. :-(
The sql_mode stuff requires MySQL 5.x :-(
No.8 | | 843 bytes |
| 
# ceo (AT) l-i-e (DOT) com / 2007-01-29 17:54:03 -0600:
MySQL is the *only* db engine that lets you get away with [bleep] like
apostrophes around numbers.
Actually, these are examples of valid SQL: INTEGER '1', FLAT '13.5'.
test=# select version();
version
PostgreSQL 8.1.3 on amd64-portbld-freebsd6.1, compiled by GCC cc (GCC) 3.4.4 [FreeBSD] 20050518
(1 row)
test=# select '13.5' * '30';
ERRR: operator is not unique: "unknown" * "unknown"
test=# select float '13.5' * integer '10';
?column?
135
(1 row)
test=# create table t (f float, i integer);
CREATE TABLE
test=# insert into t values ('13.5', '10');
INSERT 0 1
test=# select * from t;
f | i
+
13.5 | 10
(1 row)
No.9 | | 1468 bytes |
| 
Mon, January 29, 2007 6:55 pm, Roman Neuhauser wrote:
# ceo (AT) l-i-e (DOT) com / 2007-01-29 17:54:03 -0600:
>MySQL is the *only* db engine that lets you get away with [bleep]
>like
>apostrophes around numbers.
>
Actually, these are examples of valid SQL: INTEGER '1', FLAT '13.5'.
test=# select float '13.5' * integer '10';
?column?
135
(1 row)
Errrr.
Yes, you can TYPE-CAST string data into integer/float data
But you are INPUTTING string data at that point, not numeric, and
forcing PostgreSQL to convert it internally.
It's the exact analog of:
<?php
$foo = '1';
$foo = (int) $foo;
echo gettype($foo);
$bar = 1;
echo gettype($bar);
?>
test=# create table t (f float, i integer);
CREATE TABLE
test=# insert into t values ('13.5', '10');
INSERT 0 1
test=# select * from t;
f | i
+
13.5 | 10
(1 row)
I'm amazed this worked and didn't error out
It definitely USED to error out.
Looks like PostgreSQL caved in to the unwashed masses of MySQL users
who couldn't handle not putting apostrophes around everything to me
[sigh]
:-) :-) :-)
well.
I personally would prefer that the DB not accept bogus input like this.
Different strokes for different folks.
No.10 | | 818 bytes |
| 
Monday 29 January 2007 7:19 pm, Richard Lynch wrote:
Looks like PostgreSQL caved in to the unwashed masses of MySQL users
who couldn't handle not putting apostrophes around everything to me
[sigh]
:-) :-) :-)
well.
I personally would prefer that the DB not accept bogus input like this.
Different strokes for different folks.
Different strokes indeed. Personally I'd much rather one be able to just
say "quote a literal, dagnabbit" and not worry about whether it was a string
or an int. I'm sure there's some reason for it deep in the bowels of SQL
engines as they existed in the early '80s, but for anyone trying to not
hand-write every frickin' SQL query and automate common tasks it makes life
considerably more annoying.
No.11 | | 1281 bytes |
| 
Mon, January 29, 2007 7:43 pm, Larry Garfield wrote:
Monday 29 January 2007 7:19 pm, Richard Lynch wrote:
>
>Looks like PostgreSQL caved in to the unwashed masses of MySQL users
>who couldn't handle not putting apostrophes around everything to
>me
>[sigh]
>>
>:-) :-) :-)
>>
>well.
>>
>I personally would prefer that the DB not accept bogus input like
>this.
>>
>Different strokes for different folks.
>
Different strokes indeed. Personally I'd much rather one be able to
just
say "quote a literal, dagnabbit" and not worry about whether it was a
string
or an int. I'm sure there's some reason for it deep in the bowels of
SQL
engines as they existed in the early '80s, but for anyone trying to
not
hand-write every frickin' SQL query and automate common tasks it makes
life
considerably more annoying.
I can see where you are coming from, but if you don't know what data
type you have, and what data type you are using in SQL, you're already
screwed. :-)