Correct. If you are building dynamic SQL as a string within a stored proc, simple parameters aren't enough.
This kind of code is common when you need to build a dynamic where, select or order by clauses. Normally you would build this where clause in code and then, yes, use parameters. But some code shops insist that all SQL be in sprocs and ban inline sql. When you parametrize it, you only escape the first level. If you use that value in the dynamic sql string, it will again be treated as literal.
Now before you jump in and say "well thats a stupid way to do it! Stupid code is stupid." ask anyone who has worked in a MS SQL shop or supported 3rd party apps that use MS SQL. Even the built in system sprocs use this kind of dynamic processing. The poster's Buchner's comment was only to show that just using parameters isn't always enough.
Here is some code I wrote to prove it and tested in ms sql:
--these two lines simulate what a parametrize query would do
declare @firstname as varchar(30)
set @firstname='test''' --note the escaped single quote
declare @sqlQuery as varchar(2000)
set @sqlQuery='select * from Employee where '
if (@firstname is not null) begin
set @sqlQuery = @sqlQuery + ' Firstname=''' + @firstname + ''''
end
print @sqlQuery
exec(@sqlQuery)