Toute l'actualité de [self-access.com] en direct sur votre ordinateur !  Vous êtes ici : Accueil » Access » Tutoriaux » Access en réseauConnexion
 


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".

Vers le haut

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)

Vers le haut

Seconde technique : scinder votre application en deux

La bonne méthode consiste en fait à scinder votre application Access en deux fichiers .mdb :

  • La base dorsale (ou back-end) : ce fichier .mdb contient uniquement les tables et les relations (donc les règles d'intégrité) de votre application. Il est situé dans le dossier partagé du serveur, donc accessible à tous les utilisateurs.
  • La base frontale (ou front-end) : cet autre fichier .mdb contient tout le reste de l'application : requêtes, formulaires, états, macros et modules. Il ne contient pas les tables, mais simplement des raccourcis vers les tables réelles de la base dorsale. Il est placé sur chaque poste utilisateur.

Attention
Les modifications de la base dorsale sont bien sûr plus lourdes, puisqu'elles se font sur la base partagée. Vous retombez dans le schéma de départ : verrouillage de la base pour tout le monde. Dites à vos collègues d'aller faire un tour pendant que vous ajoutez un champ à une table, c'est la solution la plus simple !

Astuce
En fait, la base frontale peut également contenir des tables, ce qui permet éventuellement d'y stocker des informations spécifiques à chaque utilisateur (puisque ces tables ne sont pas partagées en réseau).

De cette manière, vous annulez les inconvénients vus plus haut :

  • Les performances : lorsqu'un utilisateur se connecte à la base, il ne rapatrie plus sur sa machine que les données. Les autres éléments (l'interface notamment) sont chargés directement depuis sa propre machine.
  • La mise à jour : si vous ouvrez un objet en mode Création, vous verrouillez uniquement la base frontale (la majorité des mises à jour se faisant côté applicatif, et moins souvent du côté tables). Vous pouvez donc améliorer votre base de données pendant que vos collègues continuent de travailler sur leur base frontale. Lorsque vos modifications sont terminées, vous recopiez votre base frontale sur les machines des autres utilisateurs (en écrasant leur ancienne frontale), ce qui suffit pour la mise à jour.

Vers le haut

Scinder une base Access : la pratique

  1. Ouvrez votre base Access complète (un seul fichier .mdb terminé).
  2. Cliquez sur le menu Outils / Utilitaires de base de données / Fractionner une base de données. Vous obtenez un premier écran d'introduction : cliquez sur le bouton Fractionner la base de données.
  3. 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).
  4. Cliquez sur le bouton Fractionner 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 !).

Vers le haut

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 :

  1. Ouvrez la base frontale.
  2. Cliquez sur le menu Outils / Utilitaires de base de données / Gestionnaire de tables liées.
  3. Dans la boîte Gestionnaire d'attaches, cliquez sur le bouton Sélectionner tout (vous pouvez également ne sélectionner que quelques tables, mais c'est généralement exceptionnel).
  4. Cochez la case Toujours demander un nouvel emplacement.
  5. Cliquez sur le bouton OK. Vous devrez alors sélectionner la base dorsale quelque part sur le réseau, puis valider en cliquant sur le bouton Ouvrir.

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 :
  1. Ouvrez la base frontale.
  2. Cliquez sur le menu Fichier / Données externes / Lier les tables (un clic droit dans la fenêtre Base de données fait également l'affaire).
  3. Sélectionnez la base dorsale quelque part sur le réseau, puis sélectionnez la/les table(s) de cette base qu'il faut relier à 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)

Vers le haut


Mes livres sur Access...
[cliquez pour plus d'infos]





Hit-Parade 
 
[ Copyright 1997-2018 hervé inisan, self-access.com Reproduction interdite ]