Votre base de données est-elle installée ?

base de données.
Si votre routine de configuration
n’exécute pas un script d’installation
de base de données, vous pourrez exécuter
le script après avoir déterminé
que la base de données n’est pas installée.

Le code du renvoi C dans le listing
1 illustre une technique pour vérifier
que la base de données de l’application
est installée sur le SQL Server cible – il
suffit de rechercher votre base de données
dans la collection Database de
l’objet SQL-DMO Server. Dans ce cas,
le code examine si la base de données
« VolunteerSQL » est déjà  installée. Si
elle est là , c’est fait. Dans le cas
contraire, le code déclenche une erreur
interceptable et vous pouvez installer
la base de données.

A noter que vous pouvez aussi utiliser
late binding pour faire référence à 
la collection Server.Databases – ce
pourrait être même plus simple à  coder
qu’en utilisant early binding mais,
dans ce cas, vous ne savez pas s’il existe
un objet Database pour votre base de
données nommée. J’illustrerai la technique
late binding quand j’expliquerai
la restauration de la base de données.

Si le code n’a pas trouvé une référence
à  votre base de données dans la
collection Server.Databases, vous devez
installer la base de données.
L’installation est simple si vous utilisez
la procédure cataloguée sp_detach_db
pour détacher votre base de données
MSDE de votre SQL Server de développement
et si vous sauvegardez le fichier
base de données .mdf sur le CDROM
d’installation. Avant de détacher
cette base de données, enlevez-en les
utilisateurs. Comme les ID utilisateur
ne correspondront probablement pas
sur la base de données nouvellement
installée, vous devrez peut-être recréer
les logins, utilisateur, et autorisations
valides avec un script après le réattachement.

Réattacher le fichier base de données
amputé est également facile.
L’objet Server de SQL-DMO expose la
méthode AttachDB, qui peut réattacher
un fichier base de données dans
un seul appel. La partie délicate ici est
la manière dont SQL-DMO traite des
chaînes « multi », qui définissent la manière
dont SQL Server doit traiter les
espaces imbriqués et les noms d’accès
contenant des caractères spéciaux
(SQL Server Books Online (BOL) décrit
en détail les multi chaînes). Pour
formater votre chemin d’accès comme
une multi string, veillez à  mettre entre
crochets le chemin d’accès complet
vers votre fichier .mdf, comme le
montre le code du renvoi D. Cette
mise entre crochets traite les espaces
imbriqués dans le chemin d’accès et
autres problèmes. Soyez prêt toutefois
à  intercepter les erreurs que cette méthode
engendre. Si le fichier n’est pas
trouvé ou si un autre problème survient,
vous obtiendrez une autre erreur
interceptable.

Quand la base de données est réattachée,
mais avant de l’utiliser, vous
devez exécuter un script pour installer
les ID et mots de passe utilisateur et
définir les autorisations de chaque utilisateur
pour chacune des tables utilisateur,
procédures cataloguées, et
vues. N’oubliez pas de prévoir l’autorisation
permettant à  l’utilisateur sélectionné
de sauvegarder la base de données,
ou de créer un compte admin
capable d’effectuer cette fonction de
maintenance.

Le moyen le plus simple de créer
un fichier script comme celui-ci est
d’utiliser Enterprise Manager. (Faites
un clic droit sur votre base de données
de développement et choisissez All
Tasks, Generate SQL Script. Sur l’onglet
Options, illustré figure 2, sélectionnez
Script object-level permissions
et Script SQL Server logins (Windows
and SQL Server logins). Sélectionnez
Create one file et cliquez sur OK.) Mais
pour exécuter le script, j’ai utilisé osql.
Vous pourriez aussi exécuter ce script
depuis VB, mais c’est plus difficile.
Souvenez-vous simplement qu’ADO
ne reconnaît pas l’opérateur GO qui
sépare les sections du script. Vous devrez
diviser le script pour traiter ces délimiteurs
si vous exécutez le script à 
partir de VB. Veillez à  mettre entre
guillemets le chemin de l’application
parce qu’il pourrait contenir des espaces
imbriqués. Après avoir démarré
le script osql, vous devrez attendre
qu’il se termine parce que vos opérations
suivantes compteront sur lui.
Comme précédemment, il est essentiel
ici d’utiliser l’API Sleep Windows pour
insérer un léger délai.

Dans l’étape suivante, l’application
tente de se connecter au serveur
MSDE en utilisant l’ID et les mots de
passe utilisateur que vous installez.
Pour laisser au serveur le temps de répondre,
faites attendre l’application
pendant quelques secondes. Pour coder
ce bref délai, appelez l’API Sleep
Windows pour libérer le thread de l’application pendant n secondes (8 dans
ce cas), selon la rapidité avec laquelle
le batch s’exécute sur votre système.
Ne vous contentez pas de faire une
boucle dans votre application : vous
gaspilleriez du temps de CPU dont le
processus serveur a besoin.

Quand la routine s’éveille à  nouveau,
le code rafraîchit la collection
Server.Databases et recherche la base
de données nouvellement installée. Si
la base de données n’est pas encore
dans la liste, le code attend pendant 10
secondes de plus (1 seconde à  la fois),
puis renonce, en supposant qu’une erreur
s’est produite dans le script. Vous
règlerez ces timings pour votre base de
données et système cibles. Si vous installez
sur un système plus lent ou si
une application d’arrière plan le ralentit,
ces opérations pourraient durer
plus longtemps.

A noter qu’il existe un mécanisme
simple pour capturer les erreurs que
osql génère, sauf dans le script osql luimême.
Utilisez Query Analyzer pour
éliminer les bugs qui se trouvent dans
votre script, avant de le tester et de l’exécuter sur le système cible.

Le code du renvoi E fait un shell
vers osql pour exécuter le script. A noter
que ce fichier script est dans le répertoire
path de l’application, comme
indiqué par la propriété app.path. J’ai
placé le path entre guillemets afin que
l’utilitaire osql basé sur DOS puisse
faire l’analyse syntaxique du nom du fichier
script d’entrée. J’exécute ce
script dans une fenêtre visible pour le
déboguer, mais il vaudrait mieux l’exécuter
minimisé pour l’utilisateur.
Quoiqu’il en soit, l’utilisateur ne voit
cette fenêtre DOS que la première fois
où l’application s’exécute.

Le gestionnaire d’erreurs intercepte
une variété d’erreurs que SQLDMO
et VB génèrent. La plupart des
utilisateurs ne sont pas de taille à  affronter
ces erreurs. Pour vous aider à 
déterminer ce qui s’est mal passé, utilisez
un log d’erreur comme celui du
code illustré par le renvoi F. Le code
appelle la routine RecordError, que j’ai
écrite pour simplement transférer des
informations d’erreur et d’état dans un
fichier ASCII de diagnostic.

Une alternative à  l’utilisation de
SQL-DMO pour démarrer le système
consiste à  démarrer simplement SQL
Server automatiquement à  l’aide du
SQL Service Manager quand le système
s’initialise. Mais comme votre application
est probablement l’une des nombreuses
qui s’exécuteront sur le système
de l’utilisateur, démarrer SQL
Server en faisant le pari probable que
l’application en aura besoin dans cette
session, n’a pas de sens.

ADO n’a aucune propriété qui
change d’état quand le serveur s’effondre
ou devient indisponible pour
d’autres raisons. Donc, vous ne pourrez
pas intercepter un événement si le
serveur tombe en panne. J’ai constaté
que le moyen le plus simple pour savoir
si la connexion est correcte (et si le
moteur est encore en fonctionnement)
consiste à  exécuter une simple
requête ne renvoyant pas de rowset ou
à  utiliser adExecuteNoRecords avec la
méthode Execute de l’objet
Connection en même temps qu’un
simple SELECT. Si la requête réussit,
votre serveur est en fonctionnement –
ou il l’était quand la requête s’est exécutée.
Il n’est pas garanti qu’il restera
en fonctionnement une micro-seconde
de plus après que le moteur
traite votre requête (ce qui aurait pu la
tuer). Il faut un code de traitement
d’erreurs pour réagir dans le cas où le
serveur serait en panne et devrait redémarrer.
Démarrer un serveur qui
n’est pas en fonctionnement ne peut
être fait que programmatiquement
avec SQL-DMO.