1. ACCESS : Deux produits en un ____ 4
1.1. Le Sgbd JET. 4
1.2. Le Générateur d’application. ____ 4
1.3. Les passerelles. ____ 4
2. Créer une base de données. ___ 6
2.1. Définir les tables. __ 6
2.2. Définir les clefs primaires. 7
2.3. Définir des contraintes de champs. 7
2.4. Définir les contraintes d’intégrité référentielles. 7
2.5. Remplir la base. ___ 9
3. Utiliser le générateur de requête. ___ 10
4. Créer des formulaires 12
4.1. Formulaires simples. ___ 12
4.1.1. Regarder en mode données (ouvrir). __ 12
4.1.2. Regarder en mode création (l’équerre du maçon). _ 13
4.1.3. Choisir le département dans une liste. _ 15
4.1.4. Expérimenter filtrer par formulaire. __ 15
4.2. Sous formulaires. _ 17
4.2.1. Structure d’un ensemble formulaire / sous formulaire. 17
4.2.2. Construire un ensemble formulaire / sous formulaire. _ 18
4.2.3. Conclusions intermédiaires. __ 20
4.3. Formulaires orientés affichage. _ 20
4.4. Formulaires orientés recherche. _ 21
5. Créer des états _ 22
6. Les macros ___ 24
7. Organiser l’application 28
7.1. Décider d’un ensemble cohérent de formulaires. ____ 28
7.2. Créer une barre de menu. _ 28
8. Le code Visual basic appliqué à ACCESS. 31
9. Créer des pages WEB. _ 32
10. aspects avancés et conclusions 33
10.1. L’originalité d’ACCESS. 33
10.2. Transactions et verrouillages. _ 33
10.3. Contrôles d’accès. ___ 33
10.4. Aspects multiutilisateurs. ____ 33
10.5. Domaines d’usage privilégié d’ACCESS. _ 34
Access regroupe en fait deux produits couplés :
• Un SGBD nommé JET.
• Un générateur d’application..
1.1.Le Sgbd JET.
Le sgbd JET offre pour un prix modique la plupart des fonctionnalités d’un SGBD relationnel classique. Bien qu’offrant des possibilités de fonctionnement en multiutilisateur, il est plutôt orienté informatique personnelle. Ce SGBD est également fourni avec VISUAL BASIC
1.2.Le Générateur d’application.
C’est l’apport original de ce produit qui permet la génération d’applications d’accès aux données sans frappe d’aucun code. Bien que des applications professionnelles puissent être développées avec ACCES, ce produit est souvent considéré comme destiné aux secrétaires. Sa souplesse d’utilisation le rend en effet particulièrement intéressant pour s’adapter à des besoins changeants, tels qu’on les trouve dans des activités de Direction.
1.3.Les passerelles.
Une application générée avec ACCESS peut se connecter à d’autre SGBD qu’ACCESS, en particulier via l’interface ODBC.
ACCESS et VISUAL BASIC accèdent
• soit au SGBD JET,
• soit à des SGBD puissants et multiutilisateurs, via l’interface de programmation ODBC.
ACCESS peut également récupérer des données en provenance d’autres bases bureautiques telle DBASE, ou des portions de feuilles EXCEL correctement présentées, et même du texte tabulé, dans ce dernier cas, bien sur, il est prudent de contrôler les données récupérées.
Le menu « données externes / importer » permet de recopier dans ACCESS des données récupérées de vieilles bases.
Le menu « données externes / lier » permet de lier une application ACCESS à un gros serveur SGBD, via ODBC, pour un travail en client serveur.
Le menu « exporter » permet de recopier des données ACCESS vers un autre SGBD.
2.CREER UNE BASE DE DONNEES.
Dans cet exercice nous allons créer la base « YAKA » selon le MLD établi durant la séquence « établir des modèles de données ». Avant de se précipiter sur le clavier, il faut encore décider pour chaque champ :
• Son type.
• Valeur NULL autorisée ?
• Valeur par défaut ?
• Autre contrainte.
2.1.Définir les tables.
On utilisera dans l’onglet « table » l’assistant « Créer une table en mode création »
L’utilisation de cette interface est intuitive. Attention aux types de données numériques pour lesquels il existe plusieurs sous types.
2.2.Définir les clefs primaires.
Définir pour chaque table la clef primaire, il suffit de sélectionner le champ clef puis de cliquer dans la barre d’outils sur la petite clef. Pour les clefs composites effectuer une sélection multiple en pressant la touche shift ou la touche contrôle pendant le clic.
2.3.Définir des contraintes de champs.
Pour chaque champs positionner correctement les valeurs
• Null interdit oui/non
• Valeur par défaut, attention ne mettre de valeur par défaut que si cela est justifié ; ACCESS propose systématiquement 0 par défaut pour les entiers, ce choix doit être corrigé dans la plupart des cas.
• En général on peut indexer les clefs primaires, mais il faut choisir l’option « avec doublons » pour les clefs composites.
• L’onglet « liste de choix » vous offre la possibilité de faire choisir, à la saisie, la valeur parmi une liste ; définir cette liste dès maintenant facilitera le travail de l’assistant formulaire que nous verrons plus loin.
2.4.Définir les contraintes d’intégrité référentielles.
Il faut ouvrir « Outils / relation » . On obtient une feuille vierge ; par « ajouter une table » inclure toutes les tables dans le dessin. Sur ce dessin vous créerez les contraintes d’intégrité relationnelle en tirant la souris de la clef primaire vers la clé étrangère :
On obtient la grille :
Bien vérifier les noms des champs liés. Pour une contrainte portant vers une clef primaire composite, ajouter des lignes au présent tableau.
Cocher la case « Appliquer l’intégrité référentielle »
Pour aider au maintien de l’intégrité référentielle ACCESS propose deux options :
• « Mettre à jour en cascade » ; c’est à dire répercuter les modifications des valeurs de clefs primaires vers les tables dépendantes. Cette option parfois utile ne doit être activée qu’après réflexion : « dans mon application est il parfois nécessaire de changer la valeur d’une clef primaire ? ». Dans la négative il est préférable de ne pas activer cette option.
• « Supprimer en cascade » ; cette option est dangereuse en cas d’erreur de manipulation.
Lorsque tout est terminé on obtient une image du modèle logique que l’on pourra imprimer :
De fait ACCESS utilise ce schéma à deux fins :
• Définir les contraintes d’intégrité référentielles.
• Proposer des conditions de jointure par défaut pour le générateur de requête (voir plus loin). L’expérience vous a en effet sans doute montré que dans les requêtes les conditions de jointure suivent souvent les lignes de contraintes d’intégrité référentielle.
Vous êtes cependant convié à ne pas confondre ces deux notions. Le terme relation utilisé par Microsoft prête à confusion.
Sur les liaisons le symbole « 1 » désigne la clef primaire et le signe ‘infini’ la clef étrangère, rien de plus. Ne cherchez pas à rapprocher ces conventions des cardinalités du MCD.
Les tables « Employes » et « Pieces » ne sont pas dupliquées, il s’agit ici d’une manière de dessiner choisi par Microsoft ACCESS.
2.5.Remplir la base.
Commencer à remplir la base en ouvrant les tables crées.
Vous rencontrerez probablement un problème avec les tables « département » et
« employés ». En effet lorsque vous créez le département, vous devez définir le chef, or celui ci n’existe pas encore dans la table « employés », et la contrainte d’intégrité exige que vous nommiez chef un employés existant. Alors vous pouvez essayer de créer d’abord l’employé, oui mais le département n’existe pas encore.
La solution élégante serait de faire ces deux insertions dans une même transaction avec évaluation différée des contraintes. Or puisque vous ne faîtes pas de code, il vous est impossible d’écrire cette transaction et de toutes manières Microsoft ne sait pas évaluer les contraintes de manière différée.
Supprimer, même provisoirement, les contraintes d’intégrité ne serait pas une bonne solution.
Il faut ici opérer en trois temps :
• Créer le département sans définir le chef, ce qui est possible si vous définissez ce champ avec NULL autorisé.
• Créer l’employé qui sera chef.
• Renseigner le champ chef dans la table département.
3.UTILISER LE GENERATEUR DE REQUETE.
L’une des premières taches que vous rencontrerez sera de définir les requêtes nécessaires.
Pour définir une nouvelle requête, dans l’onglet requête utiliser l’assistant : « créer une requête en mode création » ; vous pourrez ensuite :
• Soit taper votre requête dans la fenêtre texte SQL
• Soit utiliser le générateur graphique, ce générateur pratique dans les requêtes simples, ne suffit pas pour des requêtes complexes.
Nous vous proposons trois exercices :
| Exercice 02 : Requête Département et Chef |
| Indiquer pour chaque département (numéro et nom), les numéro, nom et prénom du chef |
Avec le générateur graphique vous devez obtenir :
Essayer de basculer en « affichage / SQL » pour voir le code SQL généré, noter que ACCESS utilise la syntaxe SQL92 . Il est toujours prudent de relire ce code SQL généré. Lorsque vous enregistrerez cette requête donner un nom évocateur. Une bonne habitude sera également de préfixer chaque objet pour indiquer son type ici par exemple on peut nommer la requête :RqDeptChef.
| Exercice 03 : Requête pièces et ouvriers habilités |
|
Pour chaque pièces afficher :
• Classe et référence de la pièce. • Numéro,nom et prénom des employés habilités sur cette pièce. |
| Exercice 04 : Employé et Chef |
|
Pour chaque employés, afficher le nom de son chef.
Cette exercice vous conduira à introduire deux fois la table employé dans la clause FROM ; vous devrez alors distinguer ces deux usages par des alias. |
Les formulaires forment l’interface par laquelle l’opérateur accède aux données. Lorsque vous les aurez correctement paramétrés, ils afficheront automatiquement les données adéquates. De même si l’opérateur modifie les données affichées, les modifications seront automatiquement reportées dans la base de données. C’est cette automaticité qui rend le développement ACCESS si simple, mais c’est également elle qui effraie les programmeurs, car ils perdent la maîtrise des opérations, nous discuterons cela dans le chapitre
« CONCLUSIONS »
Un formulaire est un objet lui même composé d’autres objets (ou contrôles) typiquement des champs d’affichage, chaque objet possède des propriétés qu’il faut paramètrer, par exemple la propriété source indique quel champ de la base de donnée contient l’information à afficher.
Vous pouvez créer et paramètrer ces objets à la main où utiliser un assistant, ce que nous ferons dans un premier temps. La série d’exercices proposée vous permettra de maîtriser progressivement les possibilités offertes.
Un corrigé vous est proposé sur le répertoire commun, examiner la structure d’une application est intéressant, il suffit de regarder les propriétés des divers objets.
4.1.Formulaires simples.
| Exercice 05 : Construire un formulaire sur la table « Employés » |
|
Utiliser dans l’onglet formulaire « créer un formulaire avec l’assistant ».
Nommer ce formulaire FormEmployés, par exemple. Regarder ce qui a été généré. |
4.1.1.Regarder en mode données (ouvrir).
Noter que le formulaire permet de se déplacer de ligne en ligne dans la table Employés. Il permet de lire, mais aussi de modifier et d’ajouter. Nous verrons plus loin qu’il est possible d’interdire les ajouts et mises à jour.
Bien noter que les données entrées sont validées soit :
• Lorsque l’on change de ligne
• Lorsque l’on ferme le formulaire.
• Lorsque l’on clique explicitement sur enregistrement / sauvegarder l’enregistrement.
4.1.2.Regarder en mode création (l’équerre du maçon).
Ce dessin montre la structure du formulaire, le formulaire est un objet qui contient lui même d’autres objet, appelés aussi contrôles pour les objets d’affichage et de saisie.
Les propriétés du formulaire sont visibles et modifiables, par un clic droit dans l’angle haut gauche, on obtient :
La propriété capitale c’est la source des données, il s’agit d’une table ou d’une requête
SELECT.
Chaque champ possède également des propriétés que l’on peut obtenir par un clic droit dans ce champ :
Les deux propriétés capitales sont :
• Le nom de l’objet.
• Sa source, il s’agit d’un champ de la table ou de la requête source du formulaire. C’est dans la source que ACCESS va chercher la valeur à afficher. C’est également vers la source que ACCESS recopie une valeur saisie ou modifiée. Si la source n’est pas renseigné, le contrôle est dit indépendant.
Par défaut l’assistant donne à l’objet le même nom que la source, c’est une simplification mais cele prête à confusion. Renommer soigneusement vos objets en les préfixant. Dans ACCESS vous manierez un grand nombre d’objets, une stratégie de nommage systématique est indispensable.
4.1.3.Choisir le département dans une liste.
Chaque fois que possible, proposer à l’opérateur les valeurs autorisées dans une liste. Si vous avez bien défini votre table employés, l’assistant crée un contrôle liste déroulante pour la saisie du département. Regardons les propriétés de cet objet :
• Nom est le nom de l’objet, respecter des conventions de nommage
• Source contrôle est le champ de la base de données où la valeur saisie par l’opérateur sera recopié.
• Origine source indique où il faut chercher les valeurs proposées dans la liste, ici il s’agit d’une table, ne pas confondre cette notion avec la précédente.
• Contenu est le nom de la table à utiliser, ici département ; ce pourraît également être une requête.
• Nbre colonnes est le nombre de colonne à afficher.
• Colonne liée est le numéro de colonne à conserver, ici 1, le numéro du département.
4.1.4.Expérimenter filtrer par formulaire.
L’opérateur peut filtrer les résultats du formulaire par exemple pour lister les employés d’un département. Essayer filtrer par formulaire, on obtient le dessin ci après :
Chaque contrôle permet donc de fixer les critères de recherche, ACCESS propose des listes déroulantes partout fondées sur les valeurs existantes.
Un clic sur « activer le filtre » permet d’obtenir les lignes recherchées :
Regarder bien ces divers écrans pour ne pas les confondre :
• dans l’écran « filtrer par formulaire » on frappe des critères de recherche,
• dans l’écran ci dessus, une frappe ou une sélection dans une liste va provoquer une modification des données dans la base.
4.2.Sous formulaires.
| Exercice 06 : Ajouter un sous formulaire à votre formulaire employés |
| Créer un sous formulaire fondé sur la table des habilitations et l’inclure dans le formulaire FormEmployés de manière à afficher pour chaque employé la liste des pièces qu’il est habilité à assembler. |
Vous devrez obtenir ce résultat :
4.2.1.Structure d’un ensemble formulaire / sous formulaire.
Un sous formulaire est un contrôle dont la source est elle même un formulaire.
Dans cet exercice, nous nommerons ce contrôle : CadreHabilitation et le formulaire source SFormHabilitation. Le contrôle CadreHabilitation limite l’affichage de SFormHabilitation par un lien père- fils, ici on impose : même numéro d’employé. L’architecture de l’ensemble peut être représenté par le schéma :
NB : Lorsque vous utilisez un assistant, celui ci donne le même nom aux objets CadreHabilitation et SFormHabilitation. Ceci est une simplification mais gène la compréhension du mécanisme.
La barre de défilement du bas permet de parcourir les employés, vous devez observer que l’affichage du sous formulaire se met à jour automatiquement. Seules les pièces sur lesquelles l’employé est habilité sont affichées.
Le système fonctionne également en écriture, si vous ajoutez une nouvelle ligne dans le sous formulaire, ACCESS rajoute une ligne dans la table EstHabilitéA en utilisant le numéro d’employé du formulaire principal. Vous pouvez perfectionner l’ensemble en permettant de choisir la Référence Pièce dans une liste. Finalement le travail de remplissage de la table EstHabilitéA devient facile
4.2.2.Construire un ensemble formulaire / sous formulaire.
Il existe plusieurs méthodes pour construire un ensemble formulaire / sous formulaire. Nous vous proposons, non pas la plus rapide, mais celle qui permet de bien comprendre l’architecture de l’ensemble :
• Construire le formulaire principal, FormEmployés ,ici c’est déjà fait, vous pouviez utiliser l’assistant.
• Construire ce qui deviendra le sous formulaire SformHabilitation , vous pouvez utiliser l’assistant.
• Ajouter à FormEmployés un contrôle sous formulaire, vous pouvez utiliser l’assistant..
• Vérifier les propriétés de contrôle sous formulaire en cliquant dans son angle supérieur gauche. Attention la manipulation peut sembler confuse :
1. si vous cliquer dans le formulaire principal puis dans l’angle du sous formulaire, vous obtenez bien les propriétés du contrôle sous formulaire et nous en profiterons pour le renommer : CadreHabilitation ;
2. si vous cliquer d’abord dans le sous formulaire puis dans son angle, vous obtenez les propriétés du formulaire source SformHabilitation, ce qui nous intéresse moins.
Voici l’ensemble en mode création :
Et voici les propriétés du contrôle sous formulaire CadreHabilitation :
Les propriétés intéressantes sont :
• Nom : nom du contrôle sous formulaire qui encadre un formulaire et le contraint à limiter son affichage selon le critère père fils.
• Objet source : nom du formulaire contrôlé par le cadre ci avant.
• Champ père, champ fils : nom des champs dans le formulaire et le sous formulaire, dont les valeurs doivent être maintenues égales. Il s’agit ici des noms de champs des tables sous jacentes aux formulaires.
| Exercice 07 : Pièces et composants |
| Faire de même un ensemble formulaire / sous formulaire permettant de saisir, et de réafficher, les pièces et leurs composants. |
4.2.3.Conclusions intermédiaires.
Les formulaires, étudiés jusqu’à présent, permettent de faciliter le peuplement de la base, ici les tables Employés, EstHabilitéA, Pièces, SeComposeDe. Ils sont donc autorisés en lecture, ajout, modification, suppression
D’autres séries de formulaires seront consacrées aux recherches d’informations. Elles ne seront donc autorisées qu’en lecture.
4.3.Formulaires orientés affichage.
| Exercice 08 : Renseignements détaillés sur les employés |
|
Faire un ensemble formulaire / sous formulaire pour afficher :
• Dans le formulaire : numéro, nom, prénom de l’employé, nom du département et nom du chef. • Dans le sous formulaire la référence et la classe des pièces que l’ouvrier est habilité à fabriquer. Dans cet exercice formulaire et sous formulaire seront fondés non plus directement sur las tables, mais sur des requêtes qu’il faudra écrire au préalable. |
4.4.Formulaires orientés recherche.
Créer un formulaire permettant d’afficher tous les employés d’un département dont l’opérateur devra saisir le nom. Nous réaliserons cet exercice en employant plusieurs techniques.
| Exercice 09 : Filtrer par formulaire |
|
Vous avez déjà expérimenté cette solution, c’est la plus simple et la plus souple, par contre elle peut être confuse pour un opérateur inexpérimenté.
Exercice 10 : Filtrer par une requête paramétrée. |
|
Dans les exercices SQL fait jusqu’ici, on demandait par exemple :je veux tous les employés du département ‘montage’ . Bien évidemment pour obtenir les employés de la ‘comptabilité’ il faut modifier la requête ce qui n’est pas pratique. ACCESS propose une extension à SQL : les requêtes paramétrées. Dans sa forme la plus simple il suffit de remplacer la constante par un prompt de saisie entre [……….] . Lorsque cette requête doit être exécutée, une boite de saisie apparaît.
Exercice 11 : Filtrer par lien père fils. |
|
Ceci est la meilleure solution.
Créer un formulaire père qui contiendra un champ de saisie ( ou mieux une liste déroulante) pour le département visé. Attention le formulaire, le champ de saisie ou la liste déroulante n’ont pas de source associées, ils sont indépendants. Nommer votre champs de saisie. Tirer votre formulaire employés dans le père pour en faire un sous formulaire. Définir le lien père fils |
Nous verrons plus loin d’autres techniques mais qui nécessitent des macros.
| Exercice 12 : Afficher un état complet du personnel et de ses habilitations |
| Bien sur la présentation se fera par département puis par employés. |
Voici ce qu’il faudra obtenir :
• Pour ce faire on commencera par établir une réquête capable de fournir toutes les données nécessaires. Donc il faut joindre les tables Département,Employés,EstHabilitéA,Pièces
• Puis on utilisera l’assistant état en fondant l’état sur cette requête.
• En principe l’assistant propose de lui même les regroupemnts.
• En mode création on obtient donc :
• Bien regarder les groupes générés.
• Regarder les propriétes de l’état, ouvrir la fenêtre ‘trier et grouper’.
Dans les exercices étudiés jusqu’ici ACCESS savait ce qu’il devait faire selon les manipulations de l’opérateur, par exemple sélectionner correctement les enregistrements d’un sous formulaire. Tout était automatique.
Les exercices que nous allons voir maintenant sont plus complexes, et il faut indiquer à ACCESS ce qu’il doit faire. La logique est événementielle : vous avez peut être remarquée dans la fenêtre propriété une liste d’événements (après mise à jour, sur clic, sur activation etc.), le principe de la programmation événementielle est de définir pour chaque événement que l’on souhaite traiter un petit programme à exécuter. Deux langages sont disponibles : le langage macro et le langage Visual Basic. Dans les cas simples le langage macro suffit. Ce langage est spécifique d’ACCESS car les actions à entreprendre sont des actions ACCESS.
| Exercice 13 : Référencer un champ de saisie dans une requête paramétrée. |
|
Nous allons ici reprendre l’idée de l’exercice 10 en introduisant dans la requête paramètrée une référence à un champ de saisie du formulaire : on doit obtenir
SELECT Employes.NumSecu, , Employes.Prenom, Employes.NumDepartement FROM Employés WHERE (((Employes.NumDepartement)=[Formulaires]![FormEmpDuDept4]![ListDept])); Regarder bien la syntaxe de la zone soulignées. Formulaires désigne la collection de tous les formulaires que vous avec crées. FormEmpDuDept4 est un nom de formulaire. ListDept est un nom de champ du formulaire. Vous pouvez également générer cela en mode graphique en vous aidant de l’assistant magicien. Cliquer sur la baguette magique dans la barre d’outils. |
Sélectionner le formulaire qui vous intéresse puis le champ, le générateur syntaxique fera le reste.
Voici le formulaire à obtenir à obtenir en création
Noter bien que la liste de choix est dans la zone entête du formulaire et qu’elle est indépendante.
Nous pourrions penser que grâce à notre requête le formulaire afficherait les bons employés, en fait cela ne marche pas. Il faut en effet dire à ACCESS que chaque fois que l’opérateur saisi un nouveau département la requête doit être réexécutée. Ici ACCESS ne le fait pas de lui même. L’événement qui nous intéresse concerne l’objet ListDept et l’événement à considérer est Après MAJ. Associer à cet événement une macro dont la seule action sera actualiser, sans préciser de champ ici.
| Exercice 14 : Rajouter un filtre à une requête |
|
Une variante de cet exercice consiste à ne pas mettre de clause WHERE à la requête.
Cette clause sera ajoutée de manière dynamique comme suite à l’événement après MAJ sur l’objet ListDept. Nous allons définir une macro dont l’action sera appliquer filtre. Appliquer un filtre revient donc à ajouter une clause WHERE à une requête. Assez bizarrement il faut précéder cette action d’une action actualiser. |
| Exercice 15 : Ajuster de manière dynamique une liste déroulante. |
| Revenons à la création d’un département. Dans un premier temps nous avons convenu de ne pas définir de suite le chef. Ensuite nous créons les employés. Maintenant nous pouvons nommer le chef. Vous allez faire le formulaire adéquat. Bien sur il serait intéressant de choisir pour chef un employé de ce département. Vous allez donc créer une liste déroulant affichant les employés du département. |
Voici ce qu’il faudrait obtenir :
La liste déroulante aura pour requête contenu :
SELECT Employes.NumSecu, , Employes.Prenom
FROM Employés
WHERE (((Employes.NumDepartement)=
[Formulaires]![FormNommerChefDepartements]![TxtNumDepartement]));
Tout comme dans l’exercice 12, il faut demander l’actualisation de cette liste chaque fois que l’on change de département, donc de ligne dans le formulaire. Cela correspond à l’événement sur activation du formulaire lui même. Cette fois dans la macro pour l’action Actualiser il faudra préciser le champs ‘nouveau chef’
7.1.Décider d’un ensemble cohérent de formulaires.
Dans cette initiation nous avons exploré les possibilités d’ACCESS. Dans un vrai projet, il faut commencer par définir de manière logique et cohérente l’ensemble des formulaires nécessaires. Typiquement on réalise :
• Les formulaires qui permettent de remplir la base.
• Les formulaires qui permettent de visualiser les infos les plus couramment demandées.
Ces deux catégories assurent en quelques sortes l’intendance du système d’information.
• Ensuite il faut définir les formulaires qui doivent effectuer les traitements requis tels qu’ils apparaissent à l’issue de l’analyse. L’objet même de l’activité de l’entreprise. Il est possible que ces besoins se recoupent avec ceux déjà identifiés plus haut.
D’une manière générale, il est prudent de séparer les formulaires de saisies et les formulaires de consultation, les opérateurs sont souvent différents.
7.2.Créer une barre de menu.
| Exercice 16 : Créer un barre de menu |
| Pour donner un look professionnel vous créerez une barre de menu pour donner accès à vos formulaires, vous en profiterez pour les regrouper de manière logiques. |
La procédure est assez complexe mais puissante, n’hésitez pas à utiliser l’aide en ligne.
• Créer un formulaire indépendant qui sera la page d’accueil.
• Aller dans Affichage ->Barre d’outil->personnaliser->Barre d’outils.
• Cliquer sur nouvelle.
• Donner un nom à votre barre de menu.
• Aller dans propriétés et définir : type barre de menu :
•
• Remarquer que votre menu est visible sous forme d’un petit carré, visible sur l’écran pas sur ce polycopié.
• Revenir dans l’écran ci avant pour choisir l’onglet commande.
• Choisir : « tous les formulaires ».
• Cliquer sur le formulaire qui vous intéresse et le tirer vers le menu.
• Par un clic droit sur le bouton créé, accéder à ses propriétés.
• Pour créer des menus déroulant il fallait au préalable insérer des ‘nouveaux menus’ dans le menu principal.
• Lorsque le menu est terminé il suffit de l’affecter au formulaire d’accueil.
• Dès que le formulaire d’accueil est ouvert votre menu remplace le menu ACCESS.
• Il ne reste plus qu’à demander l’ouverture de votre formulaire d’accueil au démarrage, voir outils -> démarrage.
8. LE CODE VISUAL BASIC APPLIQUE A ACCESS.
Le langage VISUAL BASIC est une autre manière de définir les réactions d’ACCESS aux divers événements. Vous avez alors à votre disposition toute la puissance d’un vrai langage de programmation. Cette technique sort du cadre de cette initiation à ACCESS, en fait c’est de la programmation VB tout simplement. Vous accédez aux données par la couche ADO. Vous pourrez ainsi traiter les cas délicats et les transactions. Cependant si vous deviez généralisez cette manière de travailler à une grande partie de votre application ; ACCESS ne vous servirait plus à rien, autant travailler alors directement en VB.
9. CREER DES PAGES WEB.
ACCESS permet la réalisation automatique de pages WEB , trois formes sont possibles :
• Copie statique en html pur, utiliser le menu exporter.
• Fichier asp permettant de lire les dernières données, utiliser le menu exporter.
• Page dynamique permettant de lire et de mettre à jour, c’est donc l’équivalent WEB d’un formulaire.. Générer avec l’assistant page WEB d’accès aux données. La page générée est une page html avec des actives X spéciaux pour l’accès aux données. Dans cette technique le client WEB accède directement aux données par une connexion OLE DB. Pour des raisons de sécurité cette technique est plutôt à réserver à l’INTRANET. De plus elle exige Internet Explorer de Microsoft à cause des actives X.
10.1.L’originalité d’ACCESS.
ACCESS permet de développer des applications sans code, donc sans algo. La connaissance d’un langage de programmation n’est pas nécessaire. C’est donc en principe un outil pour non informaticien, mais des compétences d’analyse sont requises. La prise en main de l’outil nécessite également une formation.
Le développement est très rapide. Cependant dans des cas complexes, des difficultés risquent d’apparaître. Nous allons les examiner ci après.
10.2.Transactions et verrouillages.
L’examen de ce point délicat sort du cadre de cette initiation. Cependant ACCESS est faible de ce point de vue, et il importe donc d’en comprendre les limitations.
L’emploi d’objets liés aux données, implique des mises à jour automatiques des données. Ces mises à jour ne concernent qu’une ligne de données dans une seule table à la fois. Il n’est donc pas possible de créer de transaction comportant plusieurs requêtes.
Du point de vue verrouillage, ACCESS pratique un verrouillage optimiste, c’est à dire qu’il ne verrouille pas les données affichées. En revanche si vos données sont modifiées par un autre utilisateur, vous recevrez un message d’erreur si vous tentez vous même de modifier la même ligne.
ACCESS est donc déconseillé pour des applications où les aspects transactions et verrouillages doivent être gérés avec rigueur : virements bancaire, réservations de places train ou avion par exemple.
Il est possible de traiter correctement ces aspects en s’abstenant de créer des objets liés aux données et en effectuant les mises à jour par du code Visual Basic. Mais alors l’effort de développement est le même que pour une application VB traditionnelle.
10.3.Contrôles d’accès.
Le SGBD JET dispose de protections, il est possible des définir des utilisateurs.
Cependant ces aspects sont moins évolués que dans les serveurs SGBD type ORACLE.
Il est possible de corriger cette lacune par une architecture Client / Serveur qui permet de remplacer JET par un SGBD plus performant, tout en conservant les possibilités de génération d’application de ACCESS.
10.4.Aspects multiutilisateurs.
Le SGBD JET est capable de traiter des accès simultanés, mais la gestion des verrous n’est pas aussi rigoureuse qu’avec un SGBD serveur. Ici aussi la solution consiste à travailler en client / serveur et à traiter par code VB les transactions délicates.
10.5.Domaines d’usage privilégié d’ACCESS.
Des réserves exposées ci avant, il apparaît que à contrario, ACCESS est bien adapté aux applications bureautiques personnelles, ce qui représente une très grand domaine d’application. Dès que le nombre d’utilisateurs deviendra important, on pourra basculer en client serveur. Les transactions délicates pourront être mieux sécurisées par un traitement VISUAL BASIC. Souvent cela ne représente qu’une petite partie des traitements.
Les informaticiens traditionnels répugnent à employer ACCESS :
• Ils redoutent des difficultés pour maîtriser transactions et verrouillages.
• Le travail ‘sans code’ les déroute.
