I. Introduction▲
Il existe plusieurs méthodes pour sécuriser une application Microsoft ACCESS. Elles sont indépendantes et souvent complémentaires. Nous allons expliquer chacune d'elle et proposer un exemple pour sa mise en oeuvre.
I-A. Avertissement▲
L'utilisation de la touche F1 est vivement conseillée à tous les stades de l'utilisation d'ACCESS. L'amélioration constante de l'aide en fait un partenaire de choix dans l'apprentissage permanent d'ACCESS. Personnellement, je ne peux m'en passer, ne serait-ce que pour mémoire.
Avant d'effectuer les manipulations décritent dans ce tutoriel veillez à faire une sauvegarde des fichiers de votre application.
II. Architecture▲
Pour comprendre la sécurité nous devons faire un bref rappel des types d'architecture d'application possibles avec Microsoft ACCESS.
II-A. Fichier unique▲
Dans ce type d'architecture les données (tables) et l'interface (formulaires, états, requêtes, code, macro) sont dans le même fichier. Il est employé par de nombreux utilisateurs de Microsoft ACCESS pour des applications personnelles et mono-utilisateur.
Chaque utilisateur se connecte à l'espace de partage et lance le même fichier.
Notez que la zone de partage peut être située sur un serveur dédié ou poste utilisateur ayant un répertoire en partage.
Architecture fichier unique
Bien que ce fichier puisse être partagé et donc être accessible à plusieurs utilisateurs, il est fortement déconseillé de l'employer à cet effet.
Les accès sont fortement ralentis ;
L'infrastrucutre surcharge le réseau ;
Les méthodes de conception à base de tables temporaires deviennent lourdes à gérer ;
Le blocage d'un utilisateur peut se répercuter sur l'ensemble.
II-B. Fichier Serveur (Pseudo client serveur) ▲
Dans cette architecture les tables sont séparées de l'interface et le fichier de l'interface (frontal) est installé sur chaque poste client. Le fichier de données (dorsal) est en partage et les tables sont liées par un attachement dans chaque