escaping vs stored procedure

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:g92p4u$nkt$1@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!

Dale wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:g92p4u$nkt$1@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 wrote:
> Dale wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>> news:g92p4u$nkt$1@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.
jstucklex@attglobal.net
==================

"Curtis" <dyer85@gmail.com> wrote in message
news:Zeqtk.851$482.655@trnddc06...
> Dale wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>> news:g92p4u$nkt$1@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.

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:g95ucq$9jj$1@registered.motzarella.org...
> Curtis wrote:
>> Dale wrote:
>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
>>> news:g92p4u$nkt$1@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.

you must be right, jerry! you obviously have so much in the way of hard
facts, it should be apparent to all. i suppose 15 years of writing libraries
in many languages would make me clueless about them. what were my employers
thinking, letting me get paid to just stare at a screen all those years and
not expecting anything in return?

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

jerry's got a new word today - 'rudimentary'. i think he's had his annual
review today and that was the most frequent comment on his work, and general
personality and intellect.

as for filters, jerry...it took you a whole fucking year to figure out i was
nym-shifting. you've only recently learned how to filter based on more than
just a name. you prove the antithesis - old dog, new trick.

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

lol. you mean i confront you when you are wrong, and you get pissed and
ignore me. this is funny since almost every thread where i give a rebuttal
to your daftness, there are at least one to two others telling you you're
wrong as well. i'm the last one standing in each thread. the others give up
because you're too thick-headed and narcisistic. you give up because i don't
back down...and you know you're wrong.

the result? filter me. you make me laugh.

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

curtis and i have posted before jerry. and, as he's not a moniacle egoist
and is pretty bright, he's got no worries about being called a dipshit who
talks out of the side of his face, or a lover of the light best perceived
through the tunnel of his own ass!

"Curtis" <dyer85@gmail.com> wrote 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.

Dale wrote:
> "Curtis" <dyer85@gmail.com> wrote 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 wrote:
> Dale wrote:
>> "Curtis" <dyer85@gmail.com> wrote 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.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
> Curtis wrote:
>> Dale wrote:
>>> "Curtis" <dyer85@gmail.com> wrote 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

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:g97r22$4g2$1@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.