La sortie du programme SchemaCollector est visible sur la figure 3. Chaque entité de schéma (par ex., table, vue, procédure stockée) est scriptée dans son propre fichier individuel. Cette approche facilite l’archivage de toutes les entités du schéma dans un référentiel de code source, tel que Visual SourceSafe. Nous créons
Obtention des résultats
le nom de fichier de script approprié sur la base du nom de l’entité et en ajoutant le suffixe .sql pour indiquer qu’il s’agit d’un script. Par exemple, pour les tables nous employons :
// Set the Script
// File Name.
scrp.Options.
FileName =
strScriptFileDir +
@"\" + strTableName
+ ".SQL";
Pour effectuer le scripting réel, nous avons besoin de référencer un nom URN (Uniform Resource Name). Il s’agit d’une adresse spéciale (ou descripteur) qui identifie de manière unique les objets SQL Server. Le codage SMO a l’aspect suivant :
// Script out this
// Table. Urn[] urn = new
Urn[1];
Urn[0] = t.Urn;
scrp.Script(urn);
A la fin de l’exécution du programme, la sortie du schéma sera située dans une arborescence de répertoires sous le chemin spécifié par l’identifiant zBASEPATH dans le fichier App.Config. Par défaut, il s’agit du chemin C:\SCHEMA.
Téléchargez cette ressource
Une DSI « broker de services » ? Recettes de Scale-ups à l’usage des grandes entreprises
Découvrez dans ce carnet d’expériences les conseils et bonnes pratiques de DSI et CTO d'organisations qui ont mené et mènent leur transformation pour devenir des brokers de services accomplis. Choix technologiques et organisationnels, types de services apportés, vitesse du changement, rapport aux métiers… ils détaillent la nature et les potentiels écueils de cette métamorphose.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
