tags:

views:

91

answers:

1

I'm a newcomer to PDO and have to say that I like it so far but I am still a bit unstable on some of the calls that it uses and the documentation is not all that solid.

I am using a couple stored procedures and from what I understand about PDO, I am forced to use prepare for this. I building a module that will store info about any errors that were caused by the user. I understand that bindParam will escape any quotes and clean the string before it's inserted into the database which is NOT what I want. I want to see the string as the user entered it for troubleshooting purposes. I have tried to forgo the bindparam calls but get errors about attempting to pass by reference. Is there a way that I can achieve this? Also open to suggestions. Thanks.

+3  A: 

bindParam doesn't ‘escape’ or ‘clean’ anything as such. It sends the string you supply it with straight into the database layer, verbatim. Any ' character included in the string will end up as a ' character in the column in the database. That's the whole point of parameterisation: there are no ‘special characters’ to worry about.

If you are having problems with passing non-references to bindParam, I suggest using bindValue instead. Actually I'd pretty much recommend using that call all the time, because the reference-taking behaviour of bindParam (and mysqli_stmt_bind_param) is confusing and almost always unwanted.

bobince
Thank YOU! I'll use bindValue instead. I'm a little confused... I was under the strong impression that when I switched from the mysql_ functions to PDO that I no longer needed mysql_real_escape_string. Please tell me that somehow PDO is handling this for me already as I have read on at least a half a dozen other places.
jim
@jim: If an answer solved your problem, please make sure to click the check mark next to it so that the person who posted gets credit :)
Matchu
Yes, you don't need `mysql_real_escape_string` with PDO. The string value goes straight into the database layer without it having to be crudely spliced into the SQL statement. Because it is not being framed in an SQL string literal, there is no need to escape anything.
bobince