Академический Документы
Профессиональный Документы
Культура Документы
ACCESS
Novembre 2002
2 - Création de la table
Dans la fenêtre Base de données choisir l'onglet table puis le bouton Nouveau...
Vous avez le choix entre poursuivre avec l'aide de l'assistant ou créer manuellement la table.
Plaçons nous dans ce dernier cas.
3 - Les champs
Pour définir un champ il faut préciser son nom, son type, sa description et ses propriétés.
• Nom de champ
Les noms des champs doivent être suffisamment clairs pour identifier les données, il est
cependant conseillé de définir des noms brefs, faciles à mémoriser et à taper (éviter, si
possible, le caractère espace).
• Type de champ
(Voir fiche d’aide en ligne « Choix du type de données d’un champ »,...)
• Taille
Limite la taille d'un champ texte ou la fourchette de valeurs d'un champ numérique.
• Format
• Masque de saisie
• Décimales
• Légende
• Valide si
Condition qui doit être satisfaite pour qu'Access accepte la valeur saisie dans le
champ.
• Message si erreur
• Null interdit
L’utilisation d’un index accélère les opérations de consultation, mais ralentit celles de
mises à jour car il y a création de l’index.
5 - Clé primaire
(Voir fiche d’aide en ligne « Clés primaires »,...)
Lorsque la liste des champs est terminée ne pas oublier de définir la clé primaire :
- cliquer sur le premier champ de la clé puis éventuellement sur les autres avec la
touche Ctrl enfoncée,
- cliquer sur le bouton « clé » ( ) ou choisir les commandes Edition puis Clé primaire.
Attention, Si vous n'avez pas créé de clé primaire le système peut en créer une, de type
compteur, lors de la sauvegarde de la table.
7 - Modification de la structure
Pour modifier la structure d'une table, dans la fenêtre Base de données choisir l'onglet
«table» puis le bouton «Modifier».
Tous les objets associés à la table doivent être fermés.
Attention : avant toute modification de structure de la table, mesurez les conséquences sur les
données existantes.
1) Formulaire dépendant
Un formulaire dépendant permet de saisir, modifier, enregistrer les informations d’une table
de la base de données.
Dans une application, on crée donc autant de formulaires dépendants qu’il y a de tables
dans la base.
2) Formulaire indépendant
Si le formulaire ne sert pas à saisir les données dans une table, il est alors indépendant.
En général, on trouve 2 types de formulaires indépendants :
- les formulaires de menu
- les formulaires de paramétrage
1 – Règles de base
Dans une application, il y a autant de formulaires dépendants que de tables.
On crée généralement des formulaires indépendants :
• pour gérer des menus,
• pour filtrer les informations affichées par un état (formulaire de paramétrage)
Des sous formulaires peuvent être utilisés dans le cas d’une relation 1 (formulaire père) à
plusieurs (formulaire fils). Les 2 formulaires doivent avoir une clé commune.
6 - Placer les contrôles (exemples de contrôles : liste, zone de texte, case à cocher …)
On placera dans la zone détail du formulaire autant de contrôles qu’il y a de champs
dans la table liée.
Les contrôles qui font le lien avec un champ de la table sont dits « dépendants ».
Points à vérifier :
1) à chaque champ de la table liée doit correspondre un contrôle dépendant. Il n’existe que 2
exceptions :
- le numéro automatique si son affichage n’est pas utile à l’utilisateur
- la clé étrangère dans le cas d’un sous formulaire (elle est renseignée
automatiquement par Access).
2) on ne pourra mettre une liste de choix que pour les champs qui sont une clé étrangère.
9 - Choisir quels seront les événements sur lesquels des actions particulières seront
déclenchées
On peut intercepter à ce niveau
• les événements associés au formulaire ( Ex : « Sur activation », « Sur fermeture » …)
• ou à un contrôle particulier (ex : « Sur réception Focus », « Après MAJ » …).
On utilise les sous-formulaires quand on veut afficher/saisir les données qui proviennent de 2
tables différentes (mais qui ont un champ en commun) sur le même écran de saisie.
Lignes_commandes
Commandes
N_commande No_ligne
N_commande
Date_commande
N_vendeur Ref_produit
No_client Quantite
Payée
Livrée
Il est possible de saisir sur le même écran de saisie les commandes et les
enregistrements du détail de la commande. Il faudra pour cela créer 2 formulaires
(1 formulaire par table) et insérer au sein du formulaire « commandes » le
formulaire « détail_commande » (qui deviendra alors sous-formulaire).
Pour créer un sous-formulaire, il faut absolument que les conditions suivantes soient
remplies :
- les 2 tables liées aux 2 formulaires doivent avoir un champ commun (dans l’exemple :
N_commande). Ce champ est défini en tant que clé primaire dans une table et en clé
étrangère dans l’autre table.
- les enregistrements de la table qui contient la clé primaire seront toujours affichés dans
le formulaire père.
- les enregistrements de la table qui contient la clé étrangère seront toujours affichés
dans le formulaire fils.
- autrement formulé, il faut qu’on ait toujours les cardinalités suivantes :
o à un enregistrement du formulaire père correspondra de 0 à n enregistrements
dans le formulaire fils
o à un enregistrement du formulaire fils correspondra 1 et 1 seul enregistrement
dans le formulaire père
Formulaire père
1 1
Formulaire fils
n 1
Ensuite, il faut bien sûr s’assurer que le mode de saisie retenu soit cohérent pour l’utilisateur.
La table générée par l’association pourra être placée en sous-formulaire dans Entité_A ou en
sous-formulaire dans Entité_B.
Table C Table C
2°) Association avec 1 cardinalité maxi = 1,n ou 0,n et 1 autre cardinalité 1,1
Exemple :
A sso c i a ti o n _ C
E n ti te _ A E N T IT E _ B
0 ,n 1 ,1
Table B
1°) il faut créer 2 formulaires (1 pour chaque table) de façon indépendante (cf. fiche création
de formulaire).
2°) on insère dans le formulaire père le formulaire qui va devenir sous-formulaire (par un
glisser-déplacer)
Enfin, il est possible de placer plusieurs sous-formulaires dans le même formulaire ou créer
plusieurs niveaux de sous-formulaires (1 formulaire qui contient un sous-formulaire qui
contient lui-même un sous-sous-formulaire). Si cela ne pose pas de difficulté technique, cela
nécessite en revanche une lourdeur au niveau de l’ergonomie. Il ne faut donc point en abuser.
Nb : dans une liste on peut afficher plusieurs lignes qui contiennent chacune
plusieurs colonnes. (Ex de liste avec 3 colonnes : code_ville, nom_ville,
nb_habitants).
Cependant, seule 1 information (1 seule colonne) est gérée par la liste : les autres
ne sont présentes qu’à titre d’affichage. Il est de plus possible de cacher la colonne
qui contient l’information gérée : fréquemment, on stocke l’information « code »
(non affichée dans la liste) et on affiche l’information « libellé » qui est plus claire
pour l’utilisateur.
Méthode à suivre
1 - Mettre en place le contrôle de type zone de liste modifiable.
Utiliser la boite à outils, assistant contrôle inactif, choisir le bouton « zone de liste
modifiable ».
Exemple :
lm_cde
zt_no
METHODE
1°) Afficher l’en-tête du formulaire (menu « affichage en-tête/pied de formulaire »)
2°) Créer une liste indépendante (on ne spécifiera rien dans la propriété « source contrôle »).
La liste ne remplit en effet aucun champ de la table.
4°) paramétrer le contenu de la liste en mettant en colonne liée le champ qui servira à la
recherche (en général la clé primaire : ici , no_cde).
5°) sur l’événement « Après Mise à Jour » de la liste, associer la macro suivante :
Sur un formulaire, le contenu de chacune des listes est chargé par Access à
l’ouverture du formulaire.
Ainsi, si le contenu d’une liste évolue pendant que le formulaire reste ouvert (exemple : on
ajoute ou supprime un enregistrement à la table lue par la liste), il n’est pas rafraîchi
automatiquement.
Par défaut, l’utilisateur ne peut pas voir les dernières mises à jour de données sans fermer et
rouvrir le formulaire.
Exemple :
Je suis sur le formulaire qui permet de saisir des individus (table individu).
La liste « organisme employeur » permet de saisir le champ code_organisme de la table
individu et affiche le contenu de la table « organismes » (code_organisme, libellé organisme).
Le bouton « nouvel organisme » permet d’ajouter un organisme qui n’existe pas encore. Sur
clic de ce bouton, le formulaire organisme s’ouvre et l’utilisateur peut ajouter un nouvel
enregistrement.
Problème : de retour sur le formulaire individu, l’organisme qui vient d’être entré n’apparaît
pas car la liste n’a pas été rafraîchie..
1°) l’action pour rafraîchir le contenu d’une liste est : « actualiser » (en précisant le nom de la
liste).
2°) L’événement à intercepter doit permettre une actualisation de la liste après la mise à jour,
l’ajout ou la suppression dans la table « organismes ».
Difficulté :
Synthèse :
Cas à gérer Evénement Action
Liste + bouton dans le même Sur réception focus de la liste Actualiser
formulaire
Liste dans le sous-formulaire « Sur entrée » du contrôle Actualiser
Dans ce dernier cas, il faut mettre le chemin complet pour accéder à la liste qui se trouve dans
le sous-formulaire (d’où le « .form »).
On peut proposer des masques de saisie pour faciliter l'entrée de données et pour contrôler les
valeurs que les utilisateurs peuvent taper dans un contrôle de zone de texte.
Par exemple, vous pouvez créer un masque de saisie pour un champ Téléphone qui vous
montre exactement comment taper un nouveau numéro: __-__-__-__-__.
Caractère Description
0 Chiffre (0 à 9, entrée obligatoire, signes plus (+) et moins (-) non acceptés).
9 Chiffre ou espace (entrée facultative, signes plus et moins non acceptés).
# Chiffre ou espace (entrée facultative, positions vierges converties en espaces en
mode édition, mais les espaces sont effacés lors de la sauvegarde des données,
signes plus et moins acceptés).
L Lettre (A à Z, entrée obligatoire).
? Lettre (A à Z, entrée facultative).
A Lettre ou chiffre (entrée obligatoire).
a Lettre ou chiffre (entrée facultative).
& Caractère quelconque ou espace (entrée obligatoire).
C Caractère quelconque ou espace (entrée facultative).
. , : ; - / Séparateur de décimales, de milliers, de date et d'heure (le caractère
effectivement utilisé dépend des paramètres de la boîte de dialogue Propriétés
pour Paramètres régionaux du Panneau de configuration Windows).
< Convertit tous les caractères en minuscules.
> Convertit tous les caractères en majuscules.
! Permet un remplissage du masque de saisie à partir de la droite et non de gauche
à droite, lorsque les caractères situés à gauche du masque de saisie sont
facultatifs. Les caractères tapés dans le masque le remplissent toujours de la
gauche vers la droite. Le point d'exclamation peut être placé n'importe où dans le
masque de saisie.
\ Affiche le caractère qui suit sous sa forme ASCII littérale (par exemple, \A
s'affiche sous la forme A).
Il peut être parfois utile de tester la cohérence d’un enregistrement avant de valider son
insertion ou sa mise à jour dans une table.
Si la cohérence n’est pas respectée (condition de macro non remplie), on annule l’événement
de mise à jour (action annuler événement).
Exemple de test :
Condition Action
CpteDom("libelle_race";"t_race";"libelle_race = AnnulerEvénement
forms!f_race!zt_libelle_race")>=1
… BoîteMsg
Dans l’exemple ci-dessus, si le libellé saisi existe déjà dans la table, on annule l’insertion du
nouvel enregistrement.
Exposé du problème.
Dans une Base de données, il faut pouvoir ajouter, modifier ou supprimer des enregistrements
sans que la cohérence de la base de données soit altérée.
Solutions à apporter.
1°) Pour éviter les incohérences dans le cas d’ajouts de données non valides
a) la première solution consiste à tester la saisie au niveau du formulaire.
Dans notre exemple, on s’assurera sur le formulaire commandes qu’on ne peut saisir qu’un
code_client qui existe dans la table clients (par l’emploi d’une liste fermée par exemple).
Inconvénients de cette solution : le test n’est placé que sur le formulaire commande. Si
l’utilisateur modifie directement la table, il n’y a aucun contrôle de saisie.
2°) Pour répercuter les modifications ou suppressions dans les tables liées.
Quand on supprime ou modifie un enregistrement, il faut vérifier que les enregistrements liés
restent cohérents.
2 solutions sont possibles pour assurer cette cohérence :
Ces procédures de mise à jour particulières sont appelées des « triggers ». Access
associent ces procédures aux événements « Sur Ajout » et « Sur mise à jour » de
la table. (ces événements ne sont pas accessibles à l’utilisateur).
Quelque soit l’endroit où la modification ou la suppression est effectuée (dans un formulaire
de saisie ou directement dans la table), les répercussions dans les tables liées se font toujours.
NB2 : Les modifications ou suppressions en cascade s’activent entre 2 tables : il faut donc le
faire pour toutes les tables du modèle.
Ex : si on supprime un client, il faut supprimer toutes les commandes correspondantes mais
également toutes les lignes commandes.
Pour cela, il faut activer la mise à jour en cascade sur la relation entre clients et commandes et
sur la relation entre commandes et lignes_commandes.
Avantages : toutes les suppressions et modifications dans les tables liées se font
automatiquement.
Inconvénients : En cas de suppression ou modification en cascade, ACCESS ne propose que
le message suivant à l’utilisateur :
S’il va trop vite ou qu’il ne comprend pas bien le sens du message, il peut ainsi effacer tous
les enregistrements liés sans s’en rendre compte.
Comme ces procédures sont gérées automatiquement par Access, il n’y a pas de possibilité de
proposer un autre message à l’utilisateur.
Soit un formulaire F1 indépendant contenant deux listes lm_client et lm_cde, elles aussi
indépendantes.
Les listes peuvent être définies à partir d’une table ou d’une requête par contre la requête
définissant lm_cde doit intégrer un critère de sélection permettant de choisir le client
Remarque : si l’utilisateur modifie le choix du client, la liste commande doit afficher les
commandes correspondantes . Pour cela, il faut actualiser la liste. : faire une macro
« actualiser » sur l’événement réception focus, par exemple, de la liste lm_cde.
2 - Spécifier les jointures entre les tables ainsi que le type (classique, gauche ou droite)
Voir fiche Jointure.
Etablir la jointure entre la clé primaire d’une table et la clé secondaire d’une autre table par un
« glisser-déplacer », puis spécifier le type de jointure :
• Jointure classique : Seuls les éléments communs des 2 tables sont affichés
• Jointure gauche ou droite : Tous les éléments d’une table sont affichés même si ils
n’ont pas de correspondance dans l’autre table
NB : par défaut, les jointures sont classiques. Pour créer une jointure gauche ou droite,
double-cliquez sur la jointure.
Lorsque l’on veut afficher des enregistrements provenant de 2 tables différentes qui ont un
champ commun, on a souvent recours à une jointure. Le résultat d’une jointure n’affiche les
enregistrements des 2 tables que si les valeurs des champs joints remplissent une condition
spécifiée.
On distingue 3 types de jointure :
- la jointure naturelle
- la jointure gauche
- la jointure droite
La plus couramment utilisée est la jointure naturelle qui ne sélectionne les enregistrements des
deux tables que si les valeurs des champs joints sont égales.
VIN
0,1 Obtenir 1,n MEDAILLE
Code vin A5
Libelle A35 Code médaille A5
Millésime N Libellé médaille A35
Couleur A8
VIN
Code vin char(5) <pk> MEDAILLE
Code médaille char(5) <fk> Code médaille char(5) <pk>
Libelle char(35) FK_VIN_OBTENIR_MEDAILLE Libellé médaille char(35)
Millésime numeric
Couleur char(8)
1) Le résultat de la jointure naturelle ne fournit que les enregistrements pour lesquels les
champs joints sont égaux (ici : le champ joint est le code médaille).
On aura donc :
Code VIN Nom vin Millésime Libellé médaille
V1 Château de Jayle 1996 Or
V2 Château de Jayle 1997 Bronze
V4 Château Doistac 1997 Bronze
V5 Clos d’Astourne 1996 Argent
Dans ACCESS, la jointure par défaut est la jointure naturelle, elle est utilisée lors de la
création de requête de sélection.
2) Le résultat de la jointure gauche fournit tous les enregistrements de la 1ère table (côté
gauche de l'opération), même si le champ joint de la table située à droite ne contient pas de
valeurs correspondantes. Les enregistrements de la table de droite ne sont combinés à ceux de
la table de gauche que si les champs joints comportent des valeurs correspondantes.
Le résultat pour notre exemple est :
Dans ACCESS, une jointure gauche est signalée par une ligne de jointure en forme de flèche
vers la droite. Pour créer une jointure gauche, il suffit de double-cliquer sur le trait
symbolisant l’association.
3) Le résultat de la jointure droite fournit tous les enregistrements de la 2ème table (côté droit
de l'opération), même si le champ joint de la table située à gauche ne contient pas de valeurs
correspondantes. Les enregistrements de la table de gauche ne sont combinés à ceux de la
table de droite que si les champs joints comportent des valeurs correspondantes.
Dans ACCESS, une jointure droite est signalée par une ligne de jointure en forme de flèche
vers la gauche. Pour créer une jointure droite, il suffit de double-cliquer sur le trait
symbolisant l’association.
2 - Analyser ce document :
Ö Faire l’inventaire des informations présentes ou utilisées pour en déduire les tables
concernées et donc la requête correspondante
3 - Construire la requête en plaçant tous les champs utilisés dans l’état, sans les calculs de
regroupement. On peut y inclure les calculs « simples » portant sur chaque ligne de la
requête.
4 - Construire l’état :
Ö Attacher l’état à la source de données (requête ou table)
L’utilisateur a ainsi la possibilité de saisir les dates de la période voulue ainsi que le service.
Une fois ces choix effectués, il ne lui reste plus qu’à imprimer ou afficher l’état en cliquant
sur un bouton.
C’est au moment où on va ouvrir l’état que l’on va appliquer les conditions choisies.
Pour que l’état prenne en compte ce filtre, il faut spécifier les conditions dans l’ argument
« Condition Where » de la macro associée à l’événement “ Sur_Clic ” du bouton “ Afficher
Etat ”.
Erreur à éviter : mettre le nom d’un contrôle de l’état dans la condition where.
Exemple :
Lorsqu’on ouvre un état avec certains critères (saisis par exemple sur un formulaire de
paramétrage), on peut obtenir un résultat qui ne contient aucune donnée lorsqu’aucun
enregistrement ne répond aux critères saisis par l’utilisateur.
Dans ce cas, ACCESS ouvre l’état et n’affiche aucune donnée, ce qui est assez déroutant pour
l’utilisateur.
Pour éviter ce problème, on peut annuler l’ouverture de l’état et afficher un message à
l’utilisateur.
Solution :
Sur l’événement « Sur aucune donnée » de l’état on associera une macro qui contient les 2
actions suivantes :
Action 1 : Boîte message (message = « il n’existe aucune donnée correspondant aux critères
saisis »)
Action 2 : Arrêt toutes macros
Nb : l’action 2 permet d’annuler la macro d’ouverture de l’état. Celui-ci n’est donc pas
affiché.
Pour recopier les critères de sélection sur l’état, il suffit de créer l’en-tête suivante (le
formulaire de paramétrage doit bien sûr rester ouvert) :
Pour afficher le nom du client sur l’état, il est nécessaire de le rechercher à partir du
code_client saisi sur le formulaire de paramétrage.
Dans l’en-tête d’état, on placera donc une zone de texte avec la source contrôle suivante :
« =rechdom(« nom » ; « clients » ;
« code_client=formulaires ![f_choix_client] ![zt_clients] »)
Par cette instruction, on recherche le contenu du champ « nom », dans la table « clients »,
pour l’enregistrement pour lequel le code_client est égal à la valeur saisie sur le formulaire de
paramétrage.
1 – Création de la macro
Si la macro appartient à un groupe de macro, dans la colonne nom de macro, indiquer son
nom.
Si la macro est conditionnelle (elle déclenche ses différentes actions à partir de différentes
conditions), utiliser la colonne condition pour définir ces dernières. Une condition n’est
écrite qu’une fois, si elle s’accompagne de plusieurs actions, indiquer trois petits points (…),
dans la colonne condition, pour la rappeler.
Dans la colonne action, choisir la ou les actions souhaitées, en les plaçant dans l’ordre de
leur exécution. Pour chacune, indiquer les arguments correspondants.
La plupart du temps une macro est exécutée à partir d’un événement. Repérer le ou les
événements qui devront déclencher l’exécution de la macro, y associer cette dernière en
indiquant son nom dans la fenêtre de propriété.
Si la macro est appelée depuis une autre macro, utiliser l’action ExécuterMacro.
Tout fichier Access a tendance à occuper une place disque de plus en plus importante au fur et
à mesure de son utilisation.
Ceci est dû à 2 facteurs :
- la place occupée par les nouveaux objets créés (formulaires, états …) ou par l’ajout de
nouveaux enregistrements dans les tables
- de l’espace disque mal géré par Access à chaque utilisation de l’application
Il est ainsi possible de remédier au 2ème facteur cité ci-dessus en compactant la base de
données. Cette opération crée un nouveau fichier « .mdb » directement utilisable.
Etapes à suivre :
1- ouvrir Access sans ouvrir de base de données
2- aller dans le menu « Outils / utilitaires de base de données / Compacter une base de
données »
3- Indiquer le nom du fichier à compacter
4- Indiquer le nouveau nom qui sera attribué au fichier compacté puis cliquer sur le
bouton « enregistrer »
Lorsque l’on crée une application, ACCESS met tous les objets (tables, formulaires, états,
macros …) dans le même fichier.
Ceci peut poser des problèmes pour le déploiement des versions de l’application auprès
d’utilisateurs.
Imaginons le cas suivant : une version 1.0 (fichier appli1.mdb) est fournie à l’utilisateur qui
commence à saisir ses données.
Quelques semaines plus tard, une version 2.0 est mise au point, incluant des états et
formulaires supplémentaires. Cette version se trouve dans le fichier appli2.mdb.
Si l’on écrase chez l’utilisateur le fichier appli1.mdb par appli2.mdb, il aura bien la dernière
version de l’application mais perdra les données qu’il avait déjà saisies.
La solution consiste donc à séparer les données des traitements dans 2 fichiers différents.
Cette solution suppose bien évidemment que le modèle des données ne soit plus modifié après
la première version.
Il faut noter également que lorsqu’access attache les tables d’un fichier, il crée un lien avec un
chemin absolu, ce qui signifie que les fichiers « tables.mdb » et « appli.mdb » doivent
toujours se trouver dans le(s) même(s) répertoire(s) d’un ordinateur à l’autre.