Re: Is bind useful for one-time queries and commands?

I disagree.

Bing is mainly useful for it separes the "code" and "data" parts of your query and checks the validity of data.

For instance, if you bind an integer parameter, bind checks that the data really is an integer value; more important, if you bind a string parameter bind escapes the characters that could be interpreted as statement by the DBMS and doing so it prevents the all-present risk of code injection if data comes from user input.

All this, checks and escaping, could be done by the program but always binding your data is a good programming practice for you can always forget a check leaving a security hole, but if you forget a bind your program doesn't work

Rule One: Do not act incautiously when confronting a little bald wrinkly smiling man.

Comment on Re: Is bind useful for one-time queries and commands? Download Code

Replies are listed 'Best First'.
Re^2: Is bind useful for one-time queries and commands? by bart (Canon) on May 19, 2008 at 12:06 UTC
if you bind a string parameter bind escapes the characters that could be interpreted as statement by the DBMS and doing so it prevents the all-present risk of code injection if data comes from user input. That's what placeholders are for, too. I mean, duh! You can combine use of placeholders with bind_param (between `prepare` and the first `execute`) to make sure only certain datatypes are acceptable. In fact, I had to do this when I used DBD::ODBC with MS-Access, in case a parameter was undefined in the first call to `execute`, because otherwise, DBI performed an implicit `bind_param` with possibly the wrong type, and I occasionally got an error in one of the next loops, with a defined value for that parameter.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Is bind useful for one-time queries and commands?
by bart (Canon) on May 19, 2008 at 12:06 UTC

if you bind a string parameter bind escapes the characters that could be interpreted as statement by the DBMS and doing so it prevents the all-present risk of code injection if data comes from user input.

You can combine use of placeholders with bind_param (between prepare and the first execute) to make sure only certain datatypes are acceptable.

In fact, I had to do this when I used DBD::ODBC with MS-Access, in case a parameter was undefined in the first call to execute, because otherwise, DBI performed an implicit bind_param with possibly the wrong type, and I occasionally got an error in one of the next loops, with a defined value for that parameter.

[reply]
[d/l]
[select]