Les erreurs d’utilisation d’ADO

ADO est une interface de base de données remarquable et sa
souplesse d’utilisation constitue l’un de ses meilleurs atouts.
Toutefois, cette qualité constitue également une arme dangereuse
pouvant se retourner contre vous lorsque vous écrivez
vos applications. Voici une liste des sept erreurs les plus
fréquentes à  éviter au cours de la programmation ADO.

Erreur 7 : Ignorer le fournisseur OLE DB.
Vous pouvez employer ADO avec les fournisseurs OLE
DB natifs et le fournisseur OLE DB pour ODBC, mais ce
choix rend l’utilisation des anciens pilotes et
noms de source de données (DSN) ODBC un
peu trop facile. Le fournisseur OLE DB natif
pour SQL Server s’avère plus efficace que ces
anciennes options et permet d’accéder à  des
fonctionnalités telles que l’interface SQL
Server IRowsetFast et le rowset LinkedServer.

Erreur 6 : Utiliser des recordsets au
lieu de procédures stockées.
Bien qu’ADO vous permette d’exécuter
facilement des requêtes et des mises à  jour à 
l’aide des recordsets, les procédures stockées SQL Server
sont bien plus performantes car elles placent des plans
d’exécution en mémoire cache. Les procédures stockées
peuvent également réduire le trafic réseau en exécutant un
lot d’instructions SQL en une seule fois.

Erreur 5 : Laisser à  ADO le soin de définir les
paramètres de procédures stockées.
ADO peut détecter dynamiquement les paramètres
d’une procédure stockée en utilisant la méthode Refresh de
la collection Parameters. Vous pouvez alors facilement être
tenté de ne pas créer explicitement d’objet Parameters dans
votre code. Bien que cette fonctionnalité ait toute son utilité
au cours du développement, ne l’employez pas dans votre
code de production car elle provoquera des aller-retour inutiles
avec le serveur.

Erreur 4 : Utiliser des objets Recordset pour
toutes les mises à  jour.
Bien que cette approche permette d’actualiser une base
de données facilement et de manière conviviale, elle requiert
un curseur et, par conséquent, pas mal de ressources. La
mise à  jour de la base de données à  l’aide d’instructions SQL
ou, mieux encore, via des procédures stockées directes
constitue une méthode plus efficace, en particulier lors d’insertions,
de mises à  jour et de suppressions multiples.

Erreur 3 : Utiliser des connexions indépendantes
pour les objets Command et Recordset.
Une autre fonction mal employée d’ADO est la capacité
des objets Recordset et Command de créer leurs propres objets
Connection. Dans le cas d’applications réseau standard,
les opérations répétées de connexion et de déconnexion
sont nettement moins efficaces que la réutilisation d’un objet
Connection existant. Il existe toutefois une exception notable
à  cette règle : lorsque vous développez pour le Web et
que vous souhaitez fréquemment isoler les connexions pour
chaque page Web.

Erreur 2 : Utiliser à  tort des curseurs fortement
consommateurs de ressources.
ADO prend en charge quatre types de curseurs : à  défilement
vers l’avant uniquement, statique, à  jeu de clés et dynamique.
Parmi ceux-ci, seul le curseur à  défilement vers
l’avant uniquement est le moins consommateur de ressources
et le plus performant. Vous pouvez fréquemment
avoir la tentation d’utiliser des curseurs consommant plus de
ressources, tels que les curseurs à  jeu de clés et dynamique, pour disposer de fonctions élémentaires de défilement,
même si vous n’en avez pas besoin.

Erreur 1 : Utiliser la taille de cache de Recordset
ADO par défaut.
La propriété CacheSize de l’objet ADO Recordset
contrôle le nombre de lignes récupérées par SQL Server
lorsque ADO exécute une procédure sp_cursorfetch sur un
curseur côté serveur. L’utilisation de la valeur par défaut 1 de
la propriété CacheSize peut être inefficace et entraîner de
nombreux aller-retour avec le serveur.