I was reading Chapter 1 of your interesting book and was a bit puzzled by the solution to the Defending Against Cases of Unintended Use example. If you do not want people to use special SQL characters in the search string, why not just recode your stored procedure as a basic string comparison, like:

CREATE PROCEDURE dbo.SelectMessagesBySubjectBeginning_v2

@SubjectBeginning VARCHAR(30)

AS

SET NOCOUNT ON;

SELECT Subject, Body

FROM dbo.Messages WHERE LEFT(Subject, LEN(@SubjectBeginning)) = @SubjectBeginning;

which removes the problems with LIKE and works with searches on '[OT]' or '50%' which was one of the problem examples given?

When it comes to parameters in SQL or XSLT, the more strongly-typed the better, I would have thought. Primitive strings should be primitive strings without magical symbols.

If you wanted to provide variations on "starts-with" or "contains" or "all these words" or "exact phrase" or even "synonyms" then you could provide separate parameters. I am probably biased against wildcard searches, mind you, perhaps as they are associated in my mind with people messing about with non-atomic identifiers. 🙂