Gérer votre base de données MSDE

Cet article suppose que vous avez déjà 
installé MSDE sur votre système. Un
white paper MSDE, disponible à 
l’adresse http://www.betav.com/
files/content/whitepapers.htm, décrit
l’opération d’installation et ses particularités.

Pour accéder à  une installation
existante de la version MSDE de SQL
Server, vous devez ouvrir une
connexion ADO (ces techniques valent
aussi pour d’autres interfaces de SGBD
comme Data Access Objects – DAO –
RDO, ODBC et OLE DB). Quand votre code tente d’ouvrir une connexion, vérifiez
que le gestionnaire d’erreurs de
connexion est programmé pour traiter
d’éventuelles erreurs.

Toutefois, avant d’essayer d’ouvrir
une connexion par une quelconque interface
d’accès aux données, vous devez
vérifier au moins une fois si le moteur
MSDE est démarré. Vous pouvez
d’ailleurs vérifier périodiquement s’il
est toujours en fonctionnement.
Voyons d’abord comment vérifier si le
moteur est en fonctionnement.

ADO ne donne pas de moyens
pour démarrer SQL Server : donc si
vous essayez d’utiliser la méthode
Connection.Open avant de démarrer
le moteur, vous constaterez qu’ADO
ne peut pas se connecter. Ainsi, le message
d’erreur de la figure 1 indique soit
qu’ADO n’a pas pu trouver le serveur,
soit qu’il l’a trouvé, mais que SQL
Server ne vous a pas laissé vous
connecter pour des raisons de sécurité.
Ce message d’erreur n’est pas particulièrement
utile. Si le message était
un peu plus précis (c’est-à -dire, si
couldn’t find the server renvoyait un
message et access denied en renvoyait
un autre), vous pourriez plus facilement
écrire un gestionnaire d’erreurs
pour traiter les problèmes.

Un autre facteur de connexion est
le temps – pour que votre application
soit chargée, connectée et initialisée,
10 secondes ou plus peuvent être nécessaires.
Dans de tels cas, mes applications
ont généralement un écran «
splash » pour donner à  l’utilisateur
quelque chose à  regarder pendant que
l’application démarre, mais même
ainsi, les utilisateurs peuvent s’impatienter
au moment où le gestionnaire
d’erreurs entre en action. Le
Connection Timeout par défaut est de
15 secondes (en supposant que le LAN
est connecté à  votre NIC). Vous pourriez
réduire ce temps à  5 secondes
pour une configuration MSDE, mais
c’est encore beaucoup pour le rythme
rapide de l’environnement de travail
actuel. De plus, votre application pourrait
fort bien ne jamais démarrer si le
démarrage prend 10 secondes mais
que le processus s’arrête après 5 secondes.

Vous savez donc qu’il est important
de démarrer le serveur, ou au moins de
vérifier qu’il fonctionne avant d’utiliser
la méthode ADO Open. Vous pouvez
démarrer MSDE en utilisant SQL-DMO,
une bibliothèque d’objets qui s’installe
automatiquement quand on installe
MSDE ou SQL Server. Le modèle d’objet
SQL-DMO est plutôt lourd (il a
énormément de possibilités que vous
risquez fort de ne jamais utiliser), mais c’est un puissant outil pour réaliser des
fonctions administratives SQL Server.
Vous pouvez utiliser SQL-DMO pour
démarrer (ou redémarrer), arrêter le
serveur ? et lui faire marquer une
pause; sauvegarder, « checkpoint » et
restaurer le serveur ; gérer et installer
les bases de données, les utilisateurs,
les autorisations ; et bien plus.

Utiliser SQL-DMO pour voir si SQL
Server ou MSDE est en fonctionnement?
est plutôt simple. L’exemple de
code de cet article est extrait d’une application
MSDE mono-utilisateur que
j’ai écrite pour mon église. Je l’utiliserai pour démontrer les concepts que j’explique.
Le code du renvoi A dans le listing
1 déclare la bibliothèque d’objets
Microsoft SQL-DMO avant de référencer
les objets SQL-DMO. Avant de pouvoir
accéder au SQLDMO DLL, vous
devez aussi enregistrer la bibliothèque
SQLDMO en utilisant l’option de menu
Visual Basic (VB) Project References.
Ce DLL est installé quand vous installez
n’importe quelle version de SQL
Server sur la machine de développement.

Le code du renvoi B instancie l’objet
SQL-DMO SQL Server et appelle
SQL-DMO pour démarrer un serveur
nommé ou vérifier simplement qu’il
est démarré, en utilisant la méthode
Start de l’objet SQLServer. Dans ce cas,
il suffit de passer le nom du serveur – «
(local) » ou « . » fera l’affaire pour votre
MSDE local – et une paire ID/mot de
passe de login valide, à  la méthode
Start. J’ai utilisé sa avec le mot de passe
approprié. A l’installation, le mot de
passe sa par défaut est NULL, donc il
faut le modifier après avoir installé
MSDE pour empêcher toute personne non autorisée d’accéder aux données
de votre client. Toutefois, vous n’avez
pas besoin de sa pour démarrer le serveur
dans ce cas – juste une paire
ID/mot de passe utilisateur valide.

Si la méthode Server.Start trouve le
serveur, elle risque de déclencher une
erreur interceptable – la logique n’est
pas claire, mais le message d’erreur
éventuel indique que le serveur est
déjà  démarré. On peut comparer ce résultat
au bruit désagréable d’une clé de
contact que l’on tourne alors que le
moteur de la voiture tourne déjà . Je n’ai pas obtenu cette erreur sur mon
système Windows 98, mais la documentation
indique qu’il est possible de
déclencher une erreur sur Windows
XP, Windows 2000 ou Windows NT –
soyez donc prêt à  l’attraper.

Parfois, vous devrez accorder
quelques secondes à  SQL Server pour
qu’il réagisse après votre ordre de démarrer.
Il est judicieux de faire suivre la
méthode Server.Start d’un appel à  l’API
Windows Sleep pour accorder au serveur
10 secondes environ pour qu’il
monte en régime, avant d’enclencher
une vitesse et d’embrayer (c’est-à -dire,
avant d’exécuter votre première requête).
A noter que Sleep n’est pas une
fonction VB native. Pour l’utiliser, il
faut ajouter la déclaration suivante à 
votre projet :

Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)