1. If strings are concatenated from user input, then a user may
construct a string that makes the query do something other than what you
as the application programmer intended. A prepared statement does not
offer a user this opportunity.

A prepared statement does not perform a search and replace on a string.
It executes the prepare phase of the query to establish access paths,
then allows you to transmit only the handle to the prepared access path
and any parameters over the wire to the database. The challenge about
"general use ReplaceString" is immaterial because firebird and most
other RDBMS' have already sidestepped this issue entirely with prepared
statements.

2. Prepare is the majority of the cost of a singleton query. With a
prepared statement, you incur the prepare cost once during application
initialization. With a string concatenation, you incur the cost of the
prepare each time the query is invoked. With a prepared statement, you
incur the cost of the byte wise copy for the single value on every call.

Please read the post - the example is java. This is not a Delphi-ism.

It is standard platform independent usage of the capability of preparing
a statement once and then reusing the precomputed access path.

On Wed, 2005-12-14 at 13:00 -0500, Jason Dodson wrote:
> Thanks for the FUD. A "Prepared Statement" will be an equal "security
> risk",
> while I imagine that a Search-and-Replace on a string would take much
> longer
> than simple string concatination. As a matter of fact, I invite you to
> try and
> make a general use ReplaceString function that doesn't use string
> concatination.
>