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.
«aprile»
domlunmarmergiovensab
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011