Solitamente sono abituato a usare i parameter ma spesso lascio che sia ADO.NET a decidere per me quale sia il DataType da associare, decisione che poi si riflette - ovviamente - nella chiamata al database. La stringa viene per cui passata di default come NVARCHAR poichè in .NET la stringa è unicode. Sotto segue l'effetto che fa sul database filtrare su una colonna usando un tipo che non coincide con la colonna stessa, nel caso specifico dell'esempio qui sotto ID della tabella MyTable è di tipo CHAR.
exec sp_executesql N'SELECT * FROM [MyTable] WHERE ID = @ID', N'@ID nvarchar(12)', @ID = N'0123456789AB'
(1 row(s) affected)
Table 'MyTable'. Scan count 1, logical reads 735, physical reads 0, read-ahead reads 0.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 6 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 6 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 1 ms.
exec sp_executesql N'SELECT * FROM [MyTable] WHERE ID = @ID', N'@ID nchar(12)', @ID = N'0123456789AB'
(1 row(s) affected)
Table 'MyTable'. Scan count 1, logical reads 735, physical reads 0, read-ahead reads 0.
SQL Server Execution Times:
CPU time = 6 ms, elapsed time = 6 ms.
SQL Server Execution Times:
CPU time = 16 ms, elapsed time = 6 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
exec sp_executesql N'SELECT * FROM [MyTable] WHERE ID = @ID', N'@ID char(12)', @ID = '0123456789AB'
(1 row(s) affected)
Table 'MyTable'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
Non sarò più pigro e scriverò sempre tutto il codice ... Non sarò più pigro e scriverò sempre tutto il codice ... Non sarò più pigro e scriverò sempre tutto il codice ...