Exécuter les scripts

et octroyer les autorisations.
Le VBScript que le listing 5 montre
ouvre une connexion vers le serveur de base de données en utilisant l’information
de connexion contenue en figure 1.
Une fois que le code VBScript a établi
une connexion, il ouvre chacun des fichiers
script .sql à  tour de rôle et exécute
les commandes qu’ils contiennent.
Après quoi, le code ouvre les fichiers de
données et importe les données statiques
dans le base de données nouvellement
créée.

Pour se connecter au serveur de
base de données, le code VBScript utilise
une connexion sans ADO DSN (Data
Source Name). Nul besoin d’un DSN
parce que le code du renvoi A dans le listing
5 utilise une connexion ADODB,
qui permet de se connecter à  la base de
données en utilisant une chaîne de
connexion dynamique. Au renvoi A,
le code crée d’abord un objet
ADODB.Connection. Cet objet est capable
d’ouvrir et de conserver une
connexion de base de données ainsi
que d’exécuter des instructions sur
cette base de données. L’objet
ADODB.Connection est le seul objet
COM que le code VBScript utilise pour
toutes les actions qui créent et peuplent
la base de données.

Toujours au renvoi A du listing 5, le
code définit SQLOLEDB comme le fournisseur
de type pour connexion. La
chaîne de connexion utilise les propriétés
MASTERDBMACHINE, MASTERDBUSER,
et MASTERDBPWD que vous
avez définies dans l’installation et que
vous modifiez dans la figure 1. Quand on
l’utilise avec le fournisseur SQLOLEDB,
la chaîne de connexion a quatre parties.
Les trois premières sont le nom de
compte (User ID), le mot de passe
(Password) et le nom de la machine serveur
(Data Source). La quatrième partie
dans la chaîne de connexion, réglée sur
Master, indique à  SQL Server quelle base
de données il doit utiliser sur le serveur
(dans cet exemple, le serveur est Initial
Catalog). On utilise la base de données
maître parce qu’elle sert de connexion
pour créer la nouvelle base de données.
Comme l’installation a besoin de se
connecter à  la base de données maître
et de créer une nouvelle base de données, le compte que la propriété
MASTERDBUSER spécifie doit être un
compte tel que le compte sa (system administrator),
qui possède des privilèges
d’administrateur sur le serveur de base
de données. Une fois la nouvelle base de
données créée, la commande SQL USE
permet de continuer l’exécution dans le
contexte de la base de données nouvellement
créée.

Au renvoi B du listing 5, le code
VBScript exécute les scripts SQL. Le
code VBScript commence par ouvrir le
fichier script .sql pour la lecture. Notons
que le second paramètre de la commande
OpenTextFile est un 1, indiquant
qu’elle lit une ligne à  la fois. Si une ligne
ne contient pas la commande GO, il faut
ajouter la commande à  la variable chaîne
et lire la ligne suivante. La boucle
continue à  ajouter des lignes provenant
du fichier script dans la variable
strCommand, jusqu’à  ce qu’elle trouve
une commande GO. Le code exécute
alors la strCommand en utilisant la
connexion de base de données. Après
l’exécution, le code efface la variable et
commence à  construire la commande
suivante.

Dans la section Générer des scripts
SQL, j’ai indiqué que l’on peut
construire des listes de tables, de vues,
et de procédures cataloguées, dynamiquement.
Pour cela, on peut tirer parti
du même concept qui sous-tend l’exécution
de la commande SQL. Par
exemple, chaque définition de table
commence par la chaîne CREATE
TABLE. Quand le code du renvoi B lit le
fichier WhsDBStructures.sql, il peut rechercher
cette chaîne puis analyser le
nom de la table à  partir de la ligne.
L’analyse syntaxique du nom permet de
remplacer les listes maintenues manuellement
des noms d’objets de bases de
données qui peuplent le code au début
du listing 4.

Le renvoi C dans le listing 5 montre
la section finale du code VBScript, qui insère
les données statiques dans la base
de données. Je donne deux avertissements
pour ce code. Notons que le quatrième
paramètre de la commande OpenTextFile comporte un danger potentiel
: le wizard DTS qui crée les fichiers
de données adopte par défaut le
texte ANSI au lieu d’Unicode. Pour supporter
des fichiers ASCII, il faut donner à 
ce paramètre la valeur par défaut 0.
L’élément suivant intéressant au niveau
du renvoi C est la commande SET IDENTITY_
INSERT, qui s’exécute avant que le
script ne commence à  lire des données.
Cette commande permet d’insérer des
valeurs explicites dans la colonne IDENTITY
d’une table. En mettant sur off la
colonne IDENTITY pendant l’insertion
de données statiques, on permet au
script de copier les données exportées
et de maintenir les mêmes identificateurs.
Vous trouverez des informations
complémentaires sur la commande SET
IDENTITY_INSERT dans SQL Server
Books Online (BOL).

Le code du renvoi C utilise la même
boucle logique de base qu’il utilise pour
lire chaque ligne provenant du fichier de
données, à  cela près que chaque ligne
de données contient le jeu complet de
valeurs de données qu’une instruction
INSERT peut utiliser. Comme je l’ai déjà 
dit, on prépare les données en plaçant le
texte statique entre guillements simples,
afin de générer le fichier. Pour que l’insertion
se passe bien, les lignes résultantes
n’ont pas besoin de manipulation.
On peut améliorer ces fichiers en
ajoutant les en-têtes de colonnes au fichier
de données exporté, en modifiant
le script pour lire la première ligne du fichier
de données, puis en utilisant cette
ligne et la ligne résultante pour les noms
de colonnes de l’instruction INSERT.