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

escaping vs stored procedure

P: n/a
if I use mysql_real_escape_string on all INSERT or UPDATE queries, then would
a stored procedure provide any extra protection?

the user has to be granted UPDATE and/or INSERT privileges anyway.

Also, I've just noticed this from the manual: "mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".

So for every occasion that I call php's mysql_real_escape_string(), that
results in traffic over the socket (or pipe) to the MySQL server, right?
Aug 26 '08 #1
Share this Question
Share on Google+
23 Replies


P: n/a
Fred wrote:
if I use mysql_real_escape_string on all INSERT or UPDATE queries, then would
a stored procedure provide any extra protection?
It depends on what you do in the stored procedure. If you do additional
checking of the data, yes. Otherwise, no.
the user has to be granted UPDATE and/or INSERT privileges anyway.

Also, I've just noticed this from the manual: "mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".
Yes - it calls the LIBRARY FUNCTION.
So for every occasion that I call php's mysql_real_escape_string(), that
results in traffic over the socket (or pipe) to the MySQL server, right?
Nope. This is performed locally in the client library. No
communications over the link is performed.

And this is the correct function to use. It will escape characters
based on the current charset being used by the connection.

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

Aug 26 '08 #2

P: n/a
..oO(Dale)
>"Fred" <Fr**@notspam.notwrote in message news:g9**********@aioe.org...
>Also, I've just noticed this from the manual: "mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".

So for every occasion that I call php's mysql_real_escape_string(), that
results in traffic over the socket (or pipe) to the MySQL server, right?

i've always balked at the notion of using mysql_real_escape_string. first,
not only does it give you a false sence of security (documented cased where
it DOESN'T prevent injection), it also ties your *validation* routines to
mysql.
Sure, but do you change your DBMS as often as your underpants?

Use PDO and prepared statements instead and you don't have to worry
about such things at all.

Micha
Aug 27 '08 #3

P: n/a
Jerry Stuckle wrote:
>>
Also, I've just noticed this from the manual: "mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".

Yes - it calls the LIBRARY FUNCTION.
ohhh... it's really (PHP's MySQL library)'s function?

not a library function in MySQL
1) is that function contained in msql.dll?

2) why wouldn't MySQL have that functionality built into itself, maybe
activated by default with a switch? wouldn't that automatically prevent a lot
of attacks? anybody who had the need could always switch it off
Aug 27 '08 #5

P: n/a

"Michael Fesser" <ne*****@gmx.dewrote in message
news:84********************************@4ax.com...
.oO(Dale)
>>"Fred" <Fr**@notspam.notwrote in message news:g9**********@aioe.org...
>>Also, I've just noticed this from the manual:
"mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".

So for every occasion that I call php's mysql_real_escape_string(), that
results in traffic over the socket (or pipe) to the MySQL server, right?

i've always balked at the notion of using mysql_real_escape_string. first,
not only does it give you a false sence of security (documented cased
where
it DOESN'T prevent injection), it also ties your *validation* routines to
mysql.

Sure, but do you change your DBMS as often as your underpants?
well, if you're a consultant i'm sure you don't want to have to start
everything from scratch. i'm sure you'd probably have a good sized library
of functional code that you'd reuse. if you tie your application to one db,
that kind of limits not only your flexibility, it also means you'll have to
reprogram your db interface when you get a client who uses, say...oracle, or
teradata, or db II or whatever.

so yes, one should be *prepared* to change DBMS at any time with minimal
change to code.
Use PDO and prepared statements instead and you don't have to worry
about such things at all.
most any db suite of functions in php allow you to use prepared
statements...why tie yourself to pdo?
Aug 27 '08 #6

P: n/a

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g9**********@registered.motzarella.org...
Fred wrote:
>if I use mysql_real_escape_string on all INSERT or UPDATE queries, then
would
a stored procedure provide any extra protection?

It depends on what you do in the stored procedure. If you do additional
checking of the data, yes. Otherwise, no.
>the user has to be granted UPDATE and/or INSERT privileges anyway.

Also, I've just noticed this from the manual: "mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".

Yes - it calls the LIBRARY FUNCTION.
>So for every occasion that I call php's mysql_real_escape_string(), that
results in traffic over the socket (or pipe) to the MySQL server, right?

Nope. This is performed locally in the client library. No communications
over the link is performed.

And this is the correct function to use. It will escape characters based
on the current charset being used by the connection.
once again jerry, you're a complete IDIOT. let me put your two statements
together:

"This is performed locally in the client library"
"based on the current charset being used by the connection"

so, in fact, Y.E.S. is the correct answer. moron!

Aug 27 '08 #7

P: n/a

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g9**********@registered.motzarella.org...
Fred wrote:
>Jerry Stuckle wrote:
>>>Also, I've just noticed this from the manual:
"mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".

Yes - it calls the LIBRARY FUNCTION.

ohhh... it's really (PHP's MySQL library)'s function?

not a library function in MySQL
1) is that function contained in msql.dll?

2) why wouldn't MySQL have that functionality built into itself, maybe
activated by default with a switch? wouldn't that automatically prevent a
lot
of attacks? anybody who had the need could always switch it off

It is a library function in MySQL. But that doesn't mean it resides on
the server.
oh, so there could be extra traffic involved in using
mysql_real_escape_string. this would be the second time you've disagreed
with yourself. at least this time you've done it in a seperate post rather
than one sentence away from when you foolishly said 'Nope. [no traffic]'.

pull your head out, jerry berry.
Aug 27 '08 #8

P: n/a

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g9**********@registered.motzarella.org...
Fred wrote:
>Jerry Stuckle wrote:
>>>Also, I've just noticed this from the manual:
"mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".

Yes - it calls the LIBRARY FUNCTION.

ohhh... it's really (PHP's MySQL library)'s function?

not a library function in MySQL
then learn to be at least functionally literate, jerry!

he asked if it was a myql library function. you said 'yes' and tagged that
response with the sarcasm and wit of a 2 year old. he then said that, oh, so
the mysql manual is right. then you say that it is NOT a lib function in
mysql.

christ almighty, fucktard!

YES, it is a mysql library function!!! it is also wrapped in PHP's mysql
dlls - which ARE LIBRARIES. jerry, once again you've spouted off at the
mouth about something you have VERY little understanding of!
Aug 27 '08 #9

P: n/a
Dale wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g9**********@registered.motzarella.org...
>Fred wrote:
>>Jerry Stuckle wrote:

Also, I've just noticed this from the manual:
"mysql_real_escape_string()
calls MySQL's library function mysql_real_escape_string".
>
Yes - it calls the LIBRARY FUNCTION.
ohhh... it's really (PHP's MySQL library)'s function?

not a library function in MySQL
1) is that function contained in msql.dll?

2) why wouldn't MySQL have that functionality built into itself, maybe
activated by default with a switch? wouldn't that automatically prevent a
lot
of attacks? anybody who had the need could always switch it off
It is a library function in MySQL. But that doesn't mean it resides on
the server.

oh, so there could be extra traffic involved in using
mysql_real_escape_string.[snip]
mysql_real_escape_string() is simply part of the MySQL C API, which is
compiled in with PHP. PHP is simply wrapping the C API.

It checks the connection's charset over an active connection (if
that's what you mean by "extra" traffic):

<URL:http://dev.mysql.com/doc/refman/5.0/en/mysql-real-escape-string.html>

mysql_escape_string() doesn't require a connection to be established.
However, unless you're using prepared statements, there's no reason
not to use mysql_real_escape_sting(), and is safe, if you know what
you're doing. You can abstract escaping in your own class if you don't
have PDO available.

this would be the second time you've disagreed
with yourself. at least this time you've done it in a seperate post rather
than one sentence away from when you foolishly said 'Nope. [no traffic]'.

pull your head out, jerry berry.
Why are you being so rude to someone who's trying to answer your
questions?

--
Curtis
Aug 28 '08 #10

P: n/a
Curtis wrote:
Dale wrote:
>"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g9**********@registered.motzarella.org...
>>Fred wrote:
Jerry Stuckle wrote:

>Also, I've just noticed this from the manual:
>"mysql_real_escape_string()
>calls MySQL's library function mysql_real_escape_string".
>>
Yes - it calls the LIBRARY FUNCTION.
ohhh... it's really (PHP's MySQL library)'s function?

not a library function in MySQL
1) is that function contained in msql.dll?

2) why wouldn't MySQL have that functionality built into itself, maybe
activated by default with a switch? wouldn't that automatically
prevent a lot
of attacks? anybody who had the need could always switch it off

It is a library function in MySQL. But that doesn't mean it resides
on the server.

oh, so there could be extra traffic involved in using
mysql_real_escape_string.[snip]

mysql_real_escape_string() is simply part of the MySQL C API, which is
compiled in with PHP. PHP is simply wrapping the C API.

It checks the connection's charset over an active connection (if that's
what you mean by "extra" traffic):

<URL:http://dev.mysql.com/doc/refman/5.0/en/mysql-real-escape-string.html>

mysql_escape_string() doesn't require a connection to be established.
However, unless you're using prepared statements, there's no reason not
to use mysql_real_escape_sting(), and is safe, if you know what you're
doing. You can abstract escaping in your own class if you don't have PDO
available.

>this would be the second time you've disagreed with yourself. at least
this time you've done it in a seperate post rather than one sentence
away from when you foolishly said 'Nope. [no traffic]'.

pull your head out, jerry berry.

Why are you being so rude to someone who's trying to answer your questions?

--
Curtis
Curtis,

Dale (/Barry/Steve/other 'nyms) is just a troll with no idea of what
he's talking about. He claims to be a programmer, but doesn't
understand even the most rudimentary aspects of computer programs - in
this case what a client library is.

He has to keep changing 'nyms because so many people have blocked him;
the only time most of us see his posts is when someone copies them in a
response. And he won't use his real name because he's afraid his
employer might find out how stupid he really is (although he claims it's
because he doesn't want to get spam - which shows he doesn't even know
how to set up the most rudimentary of spam filters).

And he really hates me because I've caught him so many times in his
ignorance. He takes every chance he can to try to insult me, but he
doesn't realize he's just showing people how ignorant he is.

I suggest you block him, also. Your day will go much better :-)

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

Aug 28 '08 #11

P: n/a

"Curtis" <dy****@gmail.comwrote in message
news:Zeqtk.851$482.655@trnddc06...
Dale wrote:
>"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g9**********@registered.motzarella.org...
>>Fred wrote:
Jerry Stuckle wrote:

>Also, I've just noticed this from the manual:
>"mysql_real_escape_string()
>calls MySQL's library function mysql_real_escape_string".
>>
Yes - it calls the LIBRARY FUNCTION.
ohhh... it's really (PHP's MySQL library)'s function?

not a library function in MySQL
1) is that function contained in msql.dll?

2) why wouldn't MySQL have that functionality built into itself, maybe
activated by default with a switch? wouldn't that automatically prevent
a lot
of attacks? anybody who had the need could always switch it off

It is a library function in MySQL. But that doesn't mean it resides on
the server.

oh, so there could be extra traffic involved in using
mysql_real_escape_string.[snip]

mysql_real_escape_string() is simply part of the MySQL C API, which is
compiled in with PHP. PHP is simply wrapping the C API.

It checks the connection's charset over an active connection (if that's
what you mean by "extra" traffic):

<URL:http://dev.mysql.com/doc/refman/5.0/en/mysql-real-escape-string.html>

mysql_escape_string() doesn't require a connection to be established.
However, unless you're using prepared statements, there's no reason not to
use mysql_real_escape_sting(), and is safe, if you know what you're doing.
You can abstract escaping in your own class if you don't have PDO
available.

>this would be the second time you've disagreed with yourself. at least
this time you've done it in a seperate post rather than one sentence away
from when you foolishly said 'Nope. [no traffic]'.

pull your head out, jerry berry.

Why are you being so rude to someone who's trying to answer your
questions?
not my questions. and, i simply did not appreciate jerry's smug, sarcastic
remark to the op. that, and the fact that he was totally wrong with his
answer. the function does require a connection and in so much, generates
traffic...which was what the op wanted clarified. the answer is 'yes', not
the 'smarter than you' 'no' the op got from fairy.

btw, i use both prepared statements and a custom escaping class for my own
stuff. i do, however, shutter at how frequently it is thrown around in this
ng that mysql_escape_string prevents sql injection. it doesn't! it only
helps. further, it doesn't work all the time.

cheers.
Aug 28 '08 #12

P: n/a

"Curtis" <dy****@gmail.comwrote in message
news:Zeqtk.851$482.655@trnddc06...

<snip>

curtis, i just reread this:
mysql_escape_string() doesn't require a connection to be established.
However, unless you're using prepared statements, there's no reason not to
use mysql_real_escape_sting(), and is safe, if you know what
there are several very good reasons not to use it. the best one i can think
of is that you are tying all of your development code to a specific db. what
if your employer changes db's, or, you are a consultant with a code base
that you're wanting to reuse? only if you abstract your db layer from your
application logic will you be able to do either of those easily. the most
common upgrade from mysql to another db is either ms sql or oracle...and
neither of them have an <db>_real_escape_string equivalent.

just a thought.
Aug 28 '08 #13

P: n/a
Dale wrote:
"Curtis" <dy****@gmail.comwrote in message
news:Zeqtk.851$482.655@trnddc06...

<snip>

curtis, i just reread this:
>mysql_escape_string() doesn't require a connection to be established.
However, unless you're using prepared statements, there's no reason not to
use mysql_real_escape_sting(), and is safe, if you know what

there are several very good reasons not to use it. the best one i can think
of is that you are tying all of your development code to a specific db. what
if your employer changes db's, or, you are a consultant with a code base
that you're wanting to reuse? only if you abstract your db layer from your
application logic will you be able to do either of those easily. the most
common upgrade from mysql to another db is either ms sql or oracle...and
neither of them have an <db>_real_escape_string equivalent.

just a thought.
Exactly, and this is an inherent problem when using the mysql, mysqli,
or postgreSQL, etc. extensions. This is why I made the point about
abstraction below.

--
Curtis
Aug 29 '08 #14

P: n/a
Curtis wrote:
Dale wrote:
>"Curtis" <dy****@gmail.comwrote in message
news:Zeqtk.851$482.655@trnddc06...

<snip>

curtis, i just reread this:
>>mysql_escape_string() doesn't require a connection to be established.
However, unless you're using prepared statements, there's no reason
not to use mysql_real_escape_sting(), and is safe, if you know what

there are several very good reasons not to use it. the best one i can
think of is that you are tying all of your development code to a
specific db. what if your employer changes db's, or, you are a
consultant with a code base that you're wanting to reuse? only if you
abstract your db layer from your
application logic will you be able to do either of those easily. the
most common upgrade from mysql to another db is either ms sql or
oracle...and neither of them have an <db>_real_escape_string equivalent.

just a thought.

Exactly, and this is an inherent problem when using the mysql, mysqli,
or postgreSQL, etc. extensions. This is why I made the point about
abstraction below.

--
Curtis
Curtis,

You can do it without PDO and still be database independent. You just
need to build a good class hierarchy.

I've got a group of classes which can access MySQL, PostGresSQL and
ODBC. Pick the one you want and you've got everything for that database
- and it's a lot more efficient than PDO (which, while flexible, is more
than a bit inefficient).

Or, if you aren't into OO programming, wrap the database functions in
your own in an include file. Have one for each type of database you
will be using, and just include the appropriate file.

Database independence is not a problem - there are several ways to do
it, not just PDO. Not properly handling your data is a big problem -
which is what this thread is all about.

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

Aug 29 '08 #15

P: n/a
Jerry Stuckle wrote:
Curtis wrote:
>Dale wrote:
>>"Curtis" <dy****@gmail.comwrote in message
news:Zeqtk.851$482.655@trnddc06...

<snip>

curtis, i just reread this:

mysql_escape_string() doesn't require a connection to be
established. However, unless you're using prepared statements,
there's no reason not to use mysql_real_escape_sting(), and is safe,
if you know what

there are several very good reasons not to use it. the best one i can
think of is that you are tying all of your development code to a
specific db. what if your employer changes db's, or, you are a
consultant with a code base that you're wanting to reuse? only if
you abstract your db layer from your
application logic will you be able to do either of those easily. the
most common upgrade from mysql to another db is either ms sql or
oracle...and neither of them have an <db>_real_escape_string equivalent.

just a thought.

Exactly, and this is an inherent problem when using the mysql, mysqli,
or postgreSQL, etc. extensions. This is why I made the point about
abstraction below.

--
Curtis

Curtis,

You can do it without PDO and still be database independent. You just
need to build a good class hierarchy.
Yeah, that was the point I was trying to get across as well, so I
think we're in agreement.
I've got a group of classes which can access MySQL, PostGresSQL and
ODBC. Pick the one you want and you've got everything for that database
- and it's a lot more efficient than PDO (which, while flexible, is more
than a bit inefficient).
Hmm, that's interesting, I never thought PDO would be less efficient.
I always just assumed PDO was more efficient, since the PHP devs do
the abstracting for you. It's a good thing I still have my own
abstraction classes around. ;-)
Or, if you aren't into OO programming, wrap the database functions in
your own in an include file. Have one for each type of database you
will be using, and just include the appropriate file.

Database independence is not a problem - there are several ways to do
it, not just PDO. Not properly handling your data is a big problem -
which is what this thread is all about.
--
Curtis
Aug 29 '08 #16

P: n/a

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g9**********@registered.motzarella.org...
Curtis wrote:
>>
<snip>
Curtis,

You can do it without PDO and still be database independent. You just
need to build a good class hierarchy.
he *mentioned* pdo. his point was about abstraction, clueless!
I've got a group of classes which can access MySQL, PostGresSQL and ODBC.
hey genius, ODBC is a compliance standard NOT a DB !!!
Pick the one you want and you've got everything for that database - and
it's a lot more efficient than PDO (which, while flexible, is more than a
bit inefficient).
unlike what i'd imagine of your code...neither efficient nor flexible.
Or, if you aren't into OO programming, wrap the database functions in your
own in an include file. Have one for each type of database you will be
using, and just include the appropriate file.

Database independence is not a problem - there are several ways to do it,
not just PDO. Not properly handling your data is a big problem - which is
what this thread is all about.
so stick to the problem. oh, and READ too. his point was about abstraction.
Aug 29 '08 #17

P: n/a
Dale wrote:
"Curtis" <dy****@gmail.comwrote in message
news:Zeqtk.851$482.655@trnddc06...
>Dale wrote:
>>"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:g9**********@registered.motzarella.org...
Fred wrote:
Jerry Stuckle wrote:
>
>>Also, I've just noticed this from the manual:
>>"mysql_real_escape_string()
>>calls MySQL's library function mysql_real_escape_string".
>>>
>Yes - it calls the LIBRARY FUNCTION.
ohhh... it's really (PHP's MySQL library)'s function?
>
not a library function in MySQL
>
>
1) is that function contained in msql.dll?
>
2) why wouldn't MySQL have that functionality built into itself, maybe
activated by default with a switch? wouldn't that automatically prevent
a lot
of attacks? anybody who had the need could always switch it off
>
It is a library function in MySQL. But that doesn't mean it resides on
the server.
oh, so there could be extra traffic involved in using
mysql_real_escape_string.[snip]
mysql_real_escape_string() is simply part of the MySQL C API, which is
compiled in with PHP. PHP is simply wrapping the C API.

It checks the connection's charset over an active connection (if that's
what you mean by "extra" traffic):

<URL:http://dev.mysql.com/doc/refman/5.0/en/mysql-real-escape-string.html>

mysql_escape_string() doesn't require a connection to be established.
However, unless you're using prepared statements, there's no reason not to
use mysql_real_escape_sting(), and is safe, if you know what you're doing.
You can abstract escaping in your own class if you don't have PDO
available.

>>this would be the second time you've disagreed with yourself. at least
this time you've done it in a seperate post rather than one sentence away
from when you foolishly said 'Nope. [no traffic]'.

pull your head out, jerry berry.
Why are you being so rude to someone who's trying to answer your
questions?

not my questions. and, i simply did not appreciate jerry's smug, sarcastic
remark to the op. that, and the fact that he was totally wrong with his
answer. the function does require a connection and in so much, generates
traffic...which was what the op wanted clarified. the answer is 'yes', not
the 'smarter than you' 'no' the op got from fairy.

btw, i use both prepared statements and a custom escaping class for my own
stuff.
can you post that? what inadequacies are in the php function?
>i do, however, shutter at how frequently it is thrown around in this
ng that mysql_escape_string prevents sql injection. it doesn't! it only
helps. further, it doesn't work all the time.
have you got a link to a page that demonstrates where mysql_real_escape_string
falls down? I'd like to see the security hole demonstrated, just for the heck
of it
>
cheers.

Aug 29 '08 #18

P: n/a
..oO(Dale)
>you can google for a myriad, but since you just want an example to see...

$id = mysql_real_escape_string($_REQUEST['id']);
$sql = "
SELECT COUNT(*) userExists
FROM users
WHERE Id = " . $id . "
";
WHERE Id = '$id'

Problem solved, if you expect a string ID. If the ID is numeric, you
want to use other functions instead, not mysql_real_escape_string().

Micha
Aug 30 '08 #19

P: n/a

"Michael Fesser" <ne*****@gmx.dewrote in message
news:qv********************************@4ax.com...
.oO(Dale)
>>you can google for a myriad, but since you just want an example to see...

$id = mysql_real_escape_string($_REQUEST['id']);
$sql = "
SELECT COUNT(*) userExists
FROM users
WHERE Id = " . $id . "
";

WHERE Id = '$id'

Problem solved, if you expect a string ID. If the ID is numeric, you
want to use other functions instead, not mysql_real_escape_string().
that's one step. i just don't see the function as helpful really. educated
programmers like yourself see solutions that don't pin one to a specific db
implementation.

cheers.
Aug 31 '08 #20

P: n/a
>Problem solved, if you expect a string ID. If the ID is numeric, you
>want to use other functions instead, not mysql_real_escape_string().

that's one step. i just don't see the function as helpful really. educated
programmers like yourself see solutions that don't pin one to a specific db
implementation.
But isn't there a problem: what mysql_real_escape_string() *needs
to do* depends on the specific db implementation, doesn't it? Aren't
what characters you *need* to escape in a string dependent on the
db implementation and the charset?

Aug 31 '08 #21

P: n/a

"Gordon Burditt" <go***********@burditt.orgwrote in message
news:pN******************************@posted.inter netamerica...
>>Problem solved, if you expect a string ID. If the ID is numeric, you
want to use other functions instead, not mysql_real_escape_string().

that's one step. i just don't see the function as helpful really. educated
programmers like yourself see solutions that don't pin one to a specific
db
implementation.

But isn't there a problem: what mysql_real_escape_string() *needs
to do* depends on the specific db implementation, doesn't it? Aren't
what characters you *need* to escape in a string dependent on the
db implementation and the charset?
that's not what i'm saying. you should be abstracting your db layer and
implementing the specifics needed based on what db you go with. as it is,
the majority of db's out there can be handled with odbc and ansi
sql...inclusive of much of that information. further, that information does
not change often, if at all. that can be hard-coded into an include which
takes away from having to create traffic between the app and the db...which
that function does.

the 'specific implementation' you are talking about is mysql. you aren't
using mysql interfaces to hit oracle. how mysql itself is
implemented/configured is a moot point. i'm talking about different db's,
not different configs of mysql.

make sense?
Aug 31 '08 #22

P: n/a
..oO(Dale)
>"Michael Fesser" <ne*****@gmx.dewrote in message
news:qv********************************@4ax.com.. .
>.oO(Dale)
>>>you can google for a myriad, but since you just want an example to see...

$id = mysql_real_escape_string($_REQUEST['id']);
$sql = "
SELECT COUNT(*) userExists
FROM users
WHERE Id = " . $id . "
";

WHERE Id = '$id'

Problem solved, if you expect a string ID. If the ID is numeric, you
want to use other functions instead, not mysql_real_escape_string().

that's one step. i just don't see the function as helpful really. educated
programmers like yourself see solutions that don't pin one to a specific db
implementation.
I use PDO with my own wrapper class around it, but still use a lot of
MySQL-specific features and SQL enhancements, simply because they are
convenient and often make life a lot easier for me. I don't plan to run
my scripts on another system, a recent LAMP is simply a requirement for
my framework.

Micha
Aug 31 '08 #23

P: n/a

"Michael Fesser" <ne*****@gmx.dewrote in message
news:f3********************************@4ax.com...
.oO(Dale)
>>"Michael Fesser" <ne*****@gmx.dewrote in message
news:qv********************************@4ax.com. ..
>>.oO(Dale)

you can google for a myriad, but since you just want an example to
see...

$id = mysql_real_escape_string($_REQUEST['id']);
$sql = "
SELECT COUNT(*) userExists
FROM users
WHERE Id = " . $id . "
";

WHERE Id = '$id'

Problem solved, if you expect a string ID. If the ID is numeric, you
want to use other functions instead, not mysql_real_escape_string().

that's one step. i just don't see the function as helpful really. educated
programmers like yourself see solutions that don't pin one to a specific
db
implementation.

I use PDO with my own wrapper class around it, but still use a lot of
MySQL-specific features and SQL enhancements, simply because they are
convenient and often make life a lot easier for me. I don't plan to run
my scripts on another system, a recent LAMP is simply a requirement for
my framework.
that's cool. that's just not the case with every employer i have.
Sep 1 '08 #24

This discussion thread is closed

Replies have been disabled for this discussion.