ACCESS 2000
Support de Formation et exercices
1
Un portail au service de la formation professionnelle
Que vous soyez étudiants, stagiaires, professionnels de terrain, formateurs, ou que vous soyez tout simplement intéressé(e) par les questions relatives aux formations professionnelle, aux métiers, vous propose un contenu mis à jour en permanence et richement illustré avec un suivi quotidien de l’actualité, et une variété de ressources documentaires, de supports de formation ,et de documents en ligne ( supports de cours, mémoires, exposés, rapports de stage … ) .
Le site propose aussi une multitude de conseils et des renseignements très utiles sur tout ce qui concerne la recherche d'un emploi ou d'un stage : offres d’emploi, offres de stage, comment rédiger sa lettre de motivation, comment faire son CV, comment se préparer à l'entret
Les forums sont mis à votre disposition, pour faire par
Le portail est basé sur un concept de gratuité intégrale du contenu & un modèle collaboratif qui favorise la culture d’Ã
Diffusion du savoir & capitalisation des
Notre Devise
Partageons notre savoir
Not
Devenir la plate-
Convaincre de plus en plus de personne
- Badr FERRASS
- contactez :
• Savoir créer une base de donnée d’après un Modèle Logiq
• Etre capable de développer une application ACCESS .
• En particulier créer des formulaires de saisies et de consultation.
• Organiser l’ensemble en une application cohérente.
• L’étude des modules Visual Basic ne fait pas partie de cette première approche
Pour chacun des thèmes
• présente les points essentiels
• renvoie Ã
Autres symboles utilisé
>>>>> gd2md-html alert: Definition term(s) ↑↑ missing definition?
(Back
A éviter à tout prix !
>>>>> gd2md-html alert: Definition term(s) ↑↑ missing definition?
(Back to top)(
Approfondissement : travail de documentation ou exercice supplémentaire, à faire individuellement
(non i
• Support de cours AVENIR
• ACCESS au quotidien (Microsoft press).
1. ACCESS : Deux produits en un ___________________________________________ 4
1.1. Le Sgbd JET. __________
1.2. Le Générateur d’application. ________________________________________________ 4
1.3. Les passer
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
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 e
4.2.3. Conclusions intermédiaires. _____________________________________________________ 20
4.3. Formulaires orientés afficha
4.4. Formulaires orientés recherche. _____________________________________________ 21
5. Créer des états _________________________________________________________ 22
6. Les macros ____________________
7. Organiser l’application _________________________________________________ 28
7.1. Décider d’un ensemble cohérent de formulaires. _______________________________
8. Le code Vi
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.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 pri
1.2.Le Générateur d’applicat
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 part
ACCESS et VISUAL BASIC accèdent
• soit au SGBD JET,
• soit à des SGBD puissants et multiutilisateurs, via l’interf
Le menu « données externes /
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
• 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é
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.
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é ét
On obtient la grille :
Bien vérifier les noms des champs liés. Pour une contrainte porta
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éra
Vous êtes cependant convié à ne pas confondre ces deux notions. Le terme relation utilisé par Microsoft prête à confusion.
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
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é n
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 R
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 ensuit
• 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 »
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.
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.
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..
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. |
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
• 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. 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.
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])); 7. ORGANISER L’APPLICATION7.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.
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. • 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. ASPECTS AVANCES ET CONCLUSIONS10.1.L’originalité d’ACCESS. 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. 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. |