Inculper le DataReader

me concentrant sur l’option
CommandBehavior.CloseConnection.
(Vous pouvez télécharger
cette application à  l’adresse http://
www.itpro.fr). Vous pouvez définir
cette option quand vous utilisez la méthode
ExecuteReader de l’objet
SqlCommand pour exécuter la requête
et renvoyer un DataReader.
Mon application de test
montre que même quand
on utilise cette option, si on
ne ferme pas explicitement
le Data-Reader (ou SqlConnection),
le pool déborde.
Et l’application émet une exception
quand le code demande
plus de connexions
que le pool n’en contiendra.
Certains développeurs
soutiennent que si vous définissez
l’option Command-
Behavior.CloseConnection,
le DataReader et sa connexion
associée se fermeront
quand le DataReader
aura fini de lire les données.
Ils ont en partie raison, mais
l’option ne se comporte
ainsi que quand on utilise
un contrôle de lien complexe
dans une application Web
ASP.NET. Faire une boucle dans un jeu
de résultats DataReader jusqu’à  la fin
de son rowset (c’est-à -dire quand
Dr.Read – la méthode Read de
DataReader – renvoie faux) ne suffit
pas pour déclencher la fermeture automatique
de la connexion. En revanche,
si vous liez à  un contrôle
bound complexe comme le DataGrid,
le contrôle ferme le DataReader et la
connexion – mais seulement si vous
avez défini l’option Command-
Behavior.CloseConnection.
Si vous exécutez une requête par
une autre méthode Execute (Execute-
Scalar, ExecuteNonQuery, Execute-
XMLReader, par exemple), il vous incombe
d’ouvrir l’objet SqlConnection
et, surtout, de le fermer quand la requête
se termine. Si vous ratez une fermeture,
les connexions orphelines
s’accumulent rapidement.