Une application Access en réseau
Une base de données peut fonctionner sur une machine autonome, pour un utilisateur individuel. Mais elle devient encore plus intéressante en réseau, car plusieurs personnes peuvent y travailler simultanément, les données restant centralisées. Bonne nouvelle : la mise en place est plutôt simple sur Access !
Note
Je suppose que vous avez un réseau sous la main, ça va aider quand même pour cet article ! Le réseau peut être de type poste à poste (du style : plusieurs machines sous Windows 98, sans serveur), ou de type client/serveur (un serveur Windows 2000 ou 2003, et des machines 98, 2000 ou XP connectées à ce serveur). Quelle que soit la configuration, il existe sur le réseau un dossier partagé auquel tous les utilisateurs concernés ont un accès en lecture et écriture.
Je suppose aussi que vous avez quelques notions de base sur les réseaux : manipuler les Favoris Réseau (ou le Voisinage Réseau, c'est la même chose), accéder à un partage réseau, lire ou écrire un chemin réseau.
Important
Access/Jet (fichiers .mdb) est un logiciel serveur de fichier, contrairement à d'autres SGBDs (dont Access/MSDE !) qui sont client/serveur. Ceci implique qu'il n'est pas prévu pour 3000 utilisateurs simultanés. Microsoft annonce 255 utilisateurs simultanés, mais c'est fortement optimiste ;-). Dans les faits, tablez plutôt un maximum de 20 utilisateurs simultanés, par beau temps :o)
Consultez l'article Jargon Access pour la différence entre les modes "serveur de fichiers" et "client/serveur".
Première technique : la fausse bonne idée
La première idée serait tout simplement de copier votre base Access (le fichier .mdb complet) sur le dossier partagé du serveur. Chaque utilisateur ayant Access sur sa machine ouvrirait la base directement au travers du réseau. Ça marche, mais sachez tout de suite que c'est une mauvaise idée. Au moins 2 raisons à cela :
- Les performances : lorsqu'un utilisateur se connecte à la base, il doit rapatrier sur sa machine toutes les données qui l'intéressent, mais également tous les éléments d'interface (formulaires, états par exemple). Si les formulaires/états sont lourds (vous avez encore joué avec les images de fond ?), votre réseau va vite saturer.
- La mise à jour : dans les versions récentes d'Access, tout passage en mode Création (vous construisez ou modifiez un formulaire, vous modifiez une table, une requête...) verrouille la base en mode Exclusif. Résultat des courses : dès que vous entamez une modification mineure sur la base de données, vous bloquez tout accès aux autres utilisateurs. Pas glop :o)
Seconde technique : scinder votre application en deux
La bonne méthode consiste en fait à scinder votre application Access en deux fichiers .mdb :
|
|
Scinder une base Access : la pratique
- Ouvrez votre base Access complète (un seul fichier .mdb terminé).
- Cliquez sur le menu O. Vous obtenez un premier écran d'introduction : cliquez sur le bouton .
- Une nouvelle boîte de dialogue apparaît, qui vous invite à créer la base de données principale. Il s'agit dans la terminologie Microsoft de la partie données de la base (les tables). Donnez à cette base un nom (par exemple : back-end.mdb, données.mdb ou dorsale.mdb), et profitez-en pour définir son emplacement sur le réseau (le dossier partagé prévu sur le serveur).
- Cliquez sur le bouton pour lancer l'opération. C'est tout !
Que s'est-il passé ?
- Une nouvelle base de données a été créée dans le dossier partagé du serveur, sous le nom chap02_données.mdb dans l'exemple ci-dessous.. A part le dossier partagé, le serveur ne nécessite aucune intervention (pas de pilotes spécifiques, pas de logiciel à installer, pas de service Windows ; Access peut d'ailleurs ne pas être installé sur le serveur, il n'y servirait à rien).
- Les requêtes, formulaires, états, macros et modules de la base originale n'ont pas été modifiés, ils continuent de fonctionner comme avant.
- La base originale (sur la machine utilisateur) ne contient plus de tables réelles, mais des raccourcis vers les tables du serveur (ces raccourcis sont représentés par une icône de table assortie d'une petite flèche). Access 2002 et 2003 affichent le chemin vers la table originale lorsque vous survolez un de ces raccourcis à la souris.

Ça marche comment ?
Dans la pratique, la scission de la base ne change rien à votre façon de travailler :
- Lorsque vous double-cliquez sur l'un des raccourcis, vous ouvrez la table située sur le serveur, de façon transparente. Vous pouvez y ajouter des données, modifier des enregistrements, supprimer des enregistrements (c'est bien sûr la base dorsale qui est affectée).
- Si vous modifiez des données en direct dans la base dorsale, les changements sont répercutés en temps réel dans la base frontale. En pratique, vous devriez peu attaquer la dorsale en direct.
- Dans la partie frontale, la création de nouvelles requêtes, de nouveaux formulaires, etc. ne change pas : vous basez ces objets sur les raccourcis des tables... qui de toute façon se comportent comme les tables d'origine.
- Vous pouvez recopier la base frontale sur les machines des autres utilisateurs. On suppose qu'ils disposent d'Access ou d'un runtime Access Access. On suppose aussi pour l'instant qu'ils ont la même configuration réseau que vous (ils "voient" le dossier partagé de la même manière que vous, avec un chemin identique ; si ce n'est pas le cas... lisez ce qui suit !).
Gestion des liaisons
En soi, la base dorsale est indépendante, elle n'est liée à aucune autre base de données. Par contre, la base frontale dépend de la base dorsale. Cette dépendance est déterminée par le chemin réseau associé à chaque table (\\Trex\partage\ dans l'exemple ci-dessus). Vous aurez quelques retouches à prévoir si :
- Vous renommez la base dorsale,
- Vous renommez le partage réseau,
- Vous déplacez la base dorsale,
- D'autres utilisateurs ne voient pas le dossier partagé sous le même nom que vous,
- Vous installez l'application chez un client qui ne dispose pas de la même configuration que vous (notamment un nom de serveur et/ou un nom de partage différent).
Dans ce genre de situation, il faut forcer Access à réactualiser les raccourcis de la base frontale pour qu'ils pointent vers le nouvel emplacement de la base dorsale. C'est parti :
- Ouvrez la base frontale.
- Cliquez sur le menu .
- Dans la boîte , cliquez sur le bouton (vous pouvez également ne sélectionner que quelques tables, mais c'est généralement exceptionnel).
- Cochez la case Toujours demander un nouvel emplacement.
- Cliquez sur le bouton . Vous devrez alors sélectionner la base dorsale quelque part sur le réseau, puis valider en cliquant sur le bouton .
En principe, au bout de quelques secondes, le rétablissement des liaisons est terminé.
Note
En mode runtime, le Gestionnaire de tables liées n'est pas disponible. Ceci signifie que vous devez prévoir une autre manière de rétablir les liaisons. Généralement, un petit programme VBA manipulant les objets TableDef fait l'affaire, mais ce n'est pas l'objet de cet article (vous trouverez des détails dans les livres Access Référence, Access Cookbook ou Access Dossiers ; voir ici pour plus de détails).
Que se passe-t-il si...
| J'ajoute une table dans la base dorsale ? |
Cette table n'est bien sûr pas liée automatiquement à la base
frontale. Comment Access pourrait-il deviner ? :o) Pour créer un raccourci de table supplémentaire dans la base frontale :
|
| Je supprime un raccourci dans la base frontale ? | La suppression d'un raccourci n'affecte pas la base dorsale. C'est donc sans risque. |
| Je supprime une table dans la base dorsale ? | La base frontale n'est pas affectée directement. Plus exactement : le raccourci y figure toujours (il n'est pas supprimé automatiquement), mais il ne fonctionne plus, bien sûr. Un double-clic sur le raccourci vous gratifiera d'une belle Injure Box :o) |


Dans cet article...
Article mis à jour le 07/02/2009