A database parameter represents a typed scalar value inside a statement that SQL Server can already parse. It does not perform text substitution. Parameters therefore work in value expressions such as predicates and inserts, but cannot replace table names, column names, keywords, or every grammar-specific literal.
Last updated: October 5, 2026.
-- Valid: @CustomerId occupies a value-expression position.
EXEC sys.sp_executesql
N'SELECT CustomerId, Name
FROM dbo.Customer
WHERE CustomerId = @CustomerId;',
N'@CustomerId int',
@CustomerId = 42;
-- Invalid: an identifier cannot be supplied as a data parameter.
SELECT * FROM @TableName;
-- Also invalid: this grammar requires a password string literal.
OPEN SYMMETRIC KEY CustomerDataKey
DECRYPTION BY PASSWORD = @KeyPassword;The first statement is compiled with a parameter in a valid value position. The other statements fail during parsing because the grammar expects an identifier or a literal token before parameter binding can occur. ORMs such as Dapper cannot change those SQL Server grammar rules.
Keep data values parameterized
Use parameters for user input, IDs, dates, search text, and other data values. This preserves type information, avoids quoting mistakes, reduces injection risk, and can improve plan reuse. Microsoft’s query-processing guide recommends separating constants from statement text with parameters.
The sp_executesql reference shows that every embedded parameter needs a definition and value.
Handle unavoidable dynamic syntax with an allowlist
When a table or sort column must vary, map a small set of accepted application values to known identifiers, quote the selected identifier with QUOTENAME(), and keep all ordinary data values parameterized. Never concatenate an unchecked identifier. Dynamic SQL should vary only the syntax that genuinely must change; its filters and inserted values should still be bound parameters.
The OPEN SYMMETRIC KEY syntax specifically requires a password literal. Rather than inserting a password into generated SQL, prefer a certificate-protected key with controlled database permissions or a narrowly scoped stored procedure. This also keeps the secret out of application-generated statement text and routine query logging. Continue with reading SQL results, stored procedure parameters, and encrypted SQL Server connections.
