ADO.NET, i parameter e l'importanza dei tipi precisi.

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 ...

posted @ giovedì 6 ottobre 2005 15:05

Print

Comments on this entry:

# re: ADO.NET, i parameter e l'importanza dei tipi precisi.

Left by Pierre Greborio at 06/10/2005 20:34
Gravatar
Ho sempre pensato che lasciar fare spesso porta più svantaggi che vantaggi e quindi ho sempre definito nel codice i tipi ed eventualmente le dimensioni dei parametri usati nello statement SQL.

Un giorno è venuto da noi (in azienda) un vero e proprio guru il quale con il suo italiano forbito mi ha convinto (gliel'ho fatto solo credere !!) che non fossero necessarie.

Il tuo post mi aiuterà ad abbassargli il compenso giornaliero. Un grazie di cuore ;-)
Comments have been closed on this topic.
«maggio»
domlunmarmergiovensab
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234