Passons à  la pratique (2)

an Instance of the
// Server class.
Server theServer = new Server(str
DBMSInstanceName);

Si l’instanciation de Server ne peut être établie, le code utilise un chemin d’exception et écrit un message d’erreur à l’écran. Si l’entité Server est créée avec succès (et si la connexion est établie), nous essayons de récupérer la version de SQL Server. (Ce n’est pas absolument nécessaire, mais nous le faisons pour être certain que nous pouvons réellement communiquer avec l’instance via SMO.) Une fois que nous avons une instance Server, nous pouvons commencer à explorer la collection Databases. La ligne suivante est la plus importante dans le code de cette section :
foreach (Database db in
theServer.Databases)
{
}

Cette instruction nous permet d’effectuer une itération sur toutes les bases de données dans la collection SMO Databases afin de trouver l’instance SQL Server à documenter. Lorsque vous examinez le code source, vous voyez qu’il évite délibérément de scripter les informations pour les bases de données exemple pubs et Northwind de SQL Server 2000, car nous n’en avons pas besoin pour l’exemple et cela gaspillera de l’espace disque. Vous pouvez aussi exclure la base de données exemple AdventureWorks de SQL Server 2005 et certaines des bases de données système sur les systèmes de production.

Toutefois, pour les systèmes de développement, vous allez probablement laisser pubs, Northwind et AdventureWorks dans votre sortie de schéma. Pour chaque base de données qu’il rencontre, le code scripte les tables, fonctions, vues, procédures stockées et rôles qu’elle contient. La logique visant à scripter les entités individuelles est similaire dans chaque cas. Le code commence par créer un objet Scripter :
// Define a Scripter object and
// set the required scripting
// options. Scripter scrp = new
Scripter(theServer);

Ensuite, le code définit les options appropriées pour l’objet Scripter. Par exemple, lors du scripting des tables, nous pouvons inclure des index et déclencheurs dans la sortie en définissant les propriétés des options de scripting comme suit :
// Set Scripting Options.
scrp.Options.Indexes = true;
scrp.Options.Triggers = true;

Une fois les options définies, le code se sert d’une instruction foreach afin de parcourir la collection d’entités SMO concernée pour la base de données et scripte les entités de schéma sous forme de texte. Le style de programmation est similaire quel que soit l’élément scripté, à savoir des tables, vues ou procédures stockées.

Par exemple, pour parcourir la collection de tables d’une base de données particulière, vous allez employer le code suivant :
// Iterate through Tables
// Collection. foreach (Table t in db.Tables)
{
}
Pour effectuer une itération sur la collection des vues, le code sera le suivant :
// Iterate through Views
// Collection. foreach (View v in db.Views)
{
}
Enfin, pour les procédures stockées, le code aura l’aspect ci-après :
// Iterate through Stored
// Procedures Collection.
foreach (StoredProcedure sp in db.StoredProcedures)
{
}
Notez que lorsque vous documentez le schéma de base de données, il est important d’inclure des contraintes.

Dans le programme SchemaCollector, la ligne
scrp.Options.DriALL = true;
inclut toutes les contraintes DRI. SMO offre une grande souplesse, de sorte que vous disposez de nombreuses options pour inclure et exclure différents types de contraintes. Pour plus d’informations sur l’inclusion de contraintes dans votre script de collecte de schéma, consultez la rubrique « ScriptingOptions Members », dans la documentation en ligne SQL Server 2005. Il vous faudra effectuer des tests dans votre environnement afin de parvenir à la combinaison d’attributs de script que vous souhaitez inclure dans votre version du script.

Sur la figure Web 1 (http://www.itpro.fr Club Abonnés), vous pouvez voir un exemple de la sortie obtenue avec les options de scripting de table que j’ai spécifiées dans le code de SchemaCollector pour cet article. Notez également que certaines informations de groupes de fichiers sont incluses par défaut lorsque le programme SchemaCollector est exécuté comme écrit. (Vous noterez les attributs ON [PRIMARY] qui sont inclus dans la sortie illustrée sur la figure Web 1.)

Mais toutes les informations de groupes de fichiers de base de données ne sont pas exposées à ce niveau. Toutefois, la rubrique « Microsoft.SqlServer. Management.Smo Namespace » dans la documentation en ligne SQL Server 2005 explique que les classes FileGroup et FileGroupCollection sont exposées au sein de cet espace de nom. En utilisant l’espace de nom Microsoft.SqlServer. Management.Smo, vous pouvez, par exemple, interroger la propriété Files du membre FileGroup pour obtenir une liste de tous les fichiers de données appartenant à un groupe de fichiers.