Les deux routes divergent

du rapport, cette différence peut
avoir son importance. La version
ADO.NET donne toute latitude, par
l’intermédiaire du code, d’exclure les
auteurs sans enregistrements enfants
dans la table Sales. Une méthode
consiste à  vérifier simplement le
nombre de lignes que renvoie la méthode
GetChildRows de Author
DataRow. S’il n’y a pas d’enregistrements
de ventes, le code n’ajoute pas
la nouvelle ligne à  la DataTable crosstab.
La manoeuvre inverse, qui consiste
à  demander à  la requête crosstab SQL
de fournir les lignes d’auteurs sans
ventes, est plus difficile mais possible.
Pour inclure tous les auteurs dans la
version dynamic SQL, vous pouvez
choisir de commencer par ajouter dans
les données source au moins un enregistrement
de ventes fictif avec une valeur
Sales de 0 pour chaque enregistrement
d’auteur qui, par ailleurs, n’a pas
de ventes. Malheureusement, cette
technique ne fonctionnera pas si vous
utilisez COUNT() comme fonction de
récapitulation parce que ces ventes fictives
compteront aussi et ce n’est pas
ce que vous voulez. La solution à  ce
problème consiste à  pré-agréger les
données source en utilisant la fonction
de récapitulation que vous voulez, puis
à  ajouter les enregistrements fictifs,
dans la mesure où chaque auteur en
obtient au moins un. Ensuite, dans la
requête crosstab, utilisez toujours
la fonction SUM(). Le code que montre
le listing 8 crée une fonction,
dbo.fn_Sales(), qui unit (UNION) les
enregistrements pré-agrégés provenant
de vwSales avec un ensemble
d’enregistrements fictifs – un pour
chaque paire auteur-magasin – que
vous générez en utilisant une jointure
croisée. Si vous remplacez
dbo.vw_Sales2 dans la requête crosstab
du listing 4 par dbo.fn_Sales(), le résultat final est le même que celui que
vous avez obtenu avec ADO.NET: tous
les auteurs figureront dans le rapport.

La méthode dynamic SQL a pour
avantage de ne pas nécessiter le
Microsoft .NET Framework. Ainsi, si
vous utilisez Visual Studio 6.0, vous
pouvez facilement créer un jeu d’enregistrements
ADO en provenance de la
table crosstab Dynamic SQL et le lier à 
un contrôle flex-grid. En revanche,
l’approche ADO.NET n’est pas forcément
liée à  SQL Server. Vous pouvez facilement l’adapter pour l’utiliser avec
de bases de données qui ne reconnaissent
pas les expressions CASE, comme
Microsoft Access.

Les curseurs de SQL Server sont
lents et coûteux en termes de ressources.
Ils constitueront l’ultime recours
quand aucune autre solution ne
convient. Dynamic SQL est inefficace
parce que SQL Server ne réutilise pas
les plans de requête qu’il génère à 
partir des chaînes SQL directement
exécutées. Il faut aussi se soucier de la sécurité quand on exécute des chaînes
SQL. J’évite les curseurs et dynamic
SQL dans la mesure du possible et c’est
précisément ce que me permet la solution
ADO.NET. Avec ADO.NET, je ne
me soucie pas de la limite de 8 000 caractères
des variables varchar et je maîtrise
mieux ma sortie qu’avec T-SQL,
comme je l’ai déjà  dit. Donc, tant que
je travaillerai dans le .NET Framework,
je m’en tiendrai à  la solution ADO.NET.