mysql_real_escape_string necessary when using prepared statements

It is by accident that I noticed that I forgot to use
mysql_real_escape_string in part of my webapp.
I tested input with following text : H=E9l=E8ne 51°56'12'' http://www.mys=
ite.org/folder
3 functions worked correctly and 1 failed:
The one that failed didn't have mysql_real_escape_string and neither
did 2 of the ones that worked: in those 2 I used prepared sql
statements (PEAR DB package). The other that I used was with
mysql_real_escape_string.

So my question: can you do without mysql_real_escape_string when using
prepared sql statements with PEAR DB-package or PDO ?

For PDO apparently you can when you use quote() and prepared
statements.

Pugi

Re: mysql_real_escape_string necessary when using prepared statements

Pugi! wrote:
> It is by accident that I noticed that I forgot to use
> mysql_real_escape_string in part of my webapp.
> I tested input with following text : Hélène 51°56'12'' http://www.mysite.org/folder
> 3 functions worked correctly and 1 failed:
> The one that failed didn't have mysql_real_escape_string and neither
> did 2 of the ones that worked: in those 2 I used prepared sql
> statements (PEAR DB package). The other that I used was with
> mysql_real_escape_string.
>
> So my question: can you do without mysql_real_escape_string when using
> prepared sql statements with PEAR DB-package or PDO ?
>
> For PDO apparently you can when you use quote() and prepared
> statements.
>
> Pugi
>

True, prepared statements don't need mysql_real_escape_string().

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

Re: mysql_real_escape_string necessary when using prepared statements

Pugi! wrote:
> It is by accident that I noticed that I forgot to use
> mysql_real_escape_string in part of my webapp.
> I tested input with following text : Hélène 51°56'12'' http://www.mysite.org/folder
> 3 functions worked correctly and 1 failed:
> The one that failed didn't have mysql_real_escape_string and neither
> did 2 of the ones that worked: in those 2 I used prepared sql
> statements (PEAR DB package). The other that I used was with
> mysql_real_escape_string.
>
> So my question: can you do without mysql_real_escape_string when using
> prepared sql statements with PEAR DB-package or PDO ?
>
> For PDO apparently you can when you use quote() and prepared
> statements.
>
> Pugi
>

True, prepared statements don't need mysql_real_escape_string().

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

Re: mysql_real_escape_string necessary when using prepared statements

Pugi! wrote:
> It is by accident that I noticed that I forgot to use
> mysql_real_escape_string in part of my webapp.
> I tested input with following text : Hélène 51°56'12'' http://www.mysite.org/folder
> 3 functions worked correctly and 1 failed:
> The one that failed didn't have mysql_real_escape_string and neither
> did 2 of the ones that worked: in those 2 I used prepared sql
> statements (PEAR DB package). The other that I used was with
> mysql_real_escape_string.
>
> So my question: can you do without mysql_real_escape_string when using
> prepared sql statements with PEAR DB-package or PDO ?
>
> For PDO apparently you can when you use quote() and prepared
> statements.
>
> Pugi
>

True, prepared statements don't need mysql_real_escape_string().

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

Re: mysql_real_escape_string necessary when using prepared statements

..oO(Pugi!)

>So my question: can you do without mysql_real_escape_string when using
>prepared sql statements with PEAR DB-package or PDO ?

Yes. That's one reason for using prepared statements - you just tell the
DMBS what kind of data you will send to it, and the server itself takes
care of the proper encoding/escaping if necessary.

>For PDO apparently you can when you use quote() and prepared
>statements.

Forget this method - it kinda defeats the purpose of prepared
statements. From the PDO->quote() manual:

| If you are using this function to build SQL statements, you are
| _strongly_ recommended to use PDO->prepare() to prepare SQL statements
| with bound parameters instead of using PDO->quote() to interpolate
| user input into a SQL statement. [...]

Micha

Re: mysql_real_escape_string necessary when using prepared statements

..oO(Pugi!)

>So my question: can you do without mysql_real_escape_string when using
>prepared sql statements with PEAR DB-package or PDO ?

Yes. That's one reason for using prepared statements - you just tell the
DMBS what kind of data you will send to it, and the server itself takes
care of the proper encoding/escaping if necessary.

>For PDO apparently you can when you use quote() and prepared
>statements.

Forget this method - it kinda defeats the purpose of prepared
statements. From the PDO->quote() manual:

| If you are using this function to build SQL statements, you are
| _strongly_ recommended to use PDO->prepare() to prepare SQL statements
| with bound parameters instead of using PDO->quote() to interpolate
| user input into a SQL statement. [...]

Micha

Re: mysql_real_escape_string necessary when using prepared statements

..oO(Pugi!)

>So my question: can you do without mysql_real_escape_string when using
>prepared sql statements with PEAR DB-package or PDO ?

Yes. That's one reason for using prepared statements - you just tell the
DMBS what kind of data you will send to it, and the server itself takes
care of the proper encoding/escaping if necessary.

>For PDO apparently you can when you use quote() and prepared
>statements.

Forget this method - it kinda defeats the purpose of prepared
statements. From the PDO->quote() manual:

| If you are using this function to build SQL statements, you are
| _strongly_ recommended to use PDO->prepare() to prepare SQL statements
| with bound parameters instead of using PDO->quote() to interpolate
| user input into a SQL statement. [...]

Micha