Exercice Access sur les requêtes Action

Pour partager cette vidéo sur les réseaux sociaux ou sur un site, voici son url :


Sujets que vous pourriez aussi aimer :


Modifier les données par les requêtes

Dans ce sixième et dernier exercice sur les requêtes Access, nous abordons les requêtes Action. Jusqu'alors, nous les avons construites pour extraire de l'information correspondant à un besoin. Mais une base de données doit vivre. Il est donc nécessaire de pouvoir mettre à jour l'information, de supprimer des données ou encore d'ajouter de nouveaux enregistrements. Pour ces tâches, Access propose des requêtes spécifiques et respectives.

Base de données source
Avant d'entrer dans le vif du sujet, nous devons commencer par récupérer les travaux des exercices précédents. Ils alimentent la base de données qui finalement produira l'application de facturation avec gestion des stocks.

• Télécharger la base clients-et-commandes-requetes-actions.accdb en cliquant sur ce lien,
• Double cliquer sur le fichier téléchargé pour l'ouvrir dans Access,
• Puis, cliquer sur le bouton Activer le contenu du bandeau de sécurité,
• Dans le volet des objets Access, double cliquer sur la requête R_doublons_villes_cp,

Nous l'avons construite dans l'exercice précédent, à l'aide de l'assistant Access. Elle permet d'extraire toutes les redondances de la table Communes. Mais ces redondances sont identifiées de façon stricte, sur la paire de champs Commune_nom et Commune_dep. En d'autres termes, pour qu'une ville soit considérée comme un doublon, son nom et son code postal doivent être strictement identiques à ceux d'un autre enregistrement. L'un des objectifs de cet exercice est de pouvoir exploiter ces résultats pour purger la table Communes de toutes ses répétitions.

Requête Mise à jour
Avant de comprendre comment il est possible de supprimer des enregistrements, nous allons apprendre à modifier des données. Dans un premier temps, nous proposons de réaliser des modifications globales, plus précisément sur les tarifs de la table Produits. Ensuite, nous verrons comment il est possible de cibler des enregistrements à actualiser, par imbrication de critères.

• Fermer la requête R_doublons_villes_cp en cliquant sur la croix de son onglet,
• Dans le volet des objets Access, cliquer sur la catégorie Tables pour déployer sa vue,
• Puis, double cliquer sur la table Produits pour l'afficher en mode feuille de données,

Comme l'indique la barre de navigation en bas de la fenêtre Access, cette table archive 245 articles.



Tous les produits de cette table sont identifiés de façon unique sur le champ produit_ref de la clé primaire. Pour absorber de nouvelles taxes, la société décide de majorer tous ses prix de vente de 5%. C'est donc le champ produit_prix de chacun de ces enregistrements qui doit être multiplié par 1,05. Vous l'avez compris, il n'est pas envisageable d'engager des mises à jour individuelles et manuelles.

• Fermer la table Produits en cliquant sur la croix de son onglet,
• En haut de la fenêtre Access, cliquer sur l'onglet Créer pour activer son ruban,
• Dans la section Requêtes du ruban, cliquer sur le bouton Création de requête,
• Dans la boîte de dialogue qui suit, sélectionner la table Produits,
• Puis, cliquer sur le bouton Ajouter et sur le bouton Fermer,

Nous basculons ainsi dans l'éditeur de requête Access.

• Dans la vue schématisée de la table, sélectionner le premier champ : produit_ref,
• Puis, tout en maintenant la touche Maj enfoncée, cliquer sur le dernier : produit_code,

Cette action a pour effet de les sélectionner tous.

• Glisser alors la sélection vers le bas sur la grille de requête,

Nous venons de déposer tous les champs normalement utiles pour la requête. Mais bien qu'à ce stade, nous soyons vraisemblablement en train de construire une requête sélection, l'objectif avoué est de réaliser la mise à jour des tarifs. Comme aucune extraction n'est envisagée, seul le champ produit_prix est nécessaire. Et nous allons le comprendre.

• En haut de la fenêtre Access, cliquer sur le bouton Mise à jour,

Par cette simple action, nous venons de modifier la nature de notre requête. Elle n'extraira plus aucune donnée. Elle les actualisera. Il reste néanmoins à définir comment. Et à ce titre, vous notez l'apparition d'une nouvelle ligne dans la grille de requête. Elle se nomme Mise à jour. C'est là que nous devons définir l'opération sur le champ ciblé.

• Dans la zone Mise à jour du champ produit_prix, saisir l'expression suivante :

[produit_prix]*1,05



Vous le savez, dans la syntaxe Access, un champ se désigne entre crochets. De fait, nous multiplions la valeur du champ produit_prix par 1,05. En d'autres termes, nous lui appliquons une majoration de 5%. Comme aucun critère n'est défini, cette majoration doit fort naturellement intervenir pour les prix de tous les articles.

• Enregistrer la requête (CTRL + S) sous le nom : R_MAJ_TS_Prix,

Comme toujours, à validation, vous voyez son nom apparaître dans le volet des objets Access. Mais cette fois, son icône change. Access alerte sur la nature de la requête, qui ne peut pas être exécutée impunément sans en être averti. Toute altération des données par une requête action est effectivement irréversible.

• Cliquer alors sur le bouton Exécuter dans le ruban contextuel Créer,

Un message d'alerte apparaît. Access demande de confirmer avec certitude. Cela va de soi, contrairement à une requête classique, nous sommes en train de toucher au coeur de l'information. Et fort logiquement, en l'absence de critère, l'avertissement indique que 245 enregistrements vont être altérés.

• Confirmer en cliquant sur le bouton Oui de la boîte de message,

Rien d'autre ne semble se produire. Aucun résultat n'est affiché. Encore une fois, il ne s'agit pas d'une requête sélection destinée à afficher les résultats de son extraction. Cette requête vient d'influer sur les données de la table Produits.

• Dans le volet des objets Access, double cliquer sur la table Produits,

En consultant le champ produit_prix, vous constatez que tous les tarifs, sans exception, ont été mis à jour. Le tout premier article était vendu à 22 Euros jusqu'alors. Après une majoration de 5%, son prix de vente a naturellement été actualisé à 23,10 Euros.

Il est important de comprendre que ces requêtes doivent être manipulées avec le plus grand soin. Maintenant qu'elle existe, à chaque exécution de la requête R_MAJ_TS_Prix, tous les prix sont de nouveau majorés.

Il est intéressant de bâtir des requêtes action capables d'agir sur des enregistrements ciblés. A l'avenir, elles permettront d'intervenir sur les données de tables par interactions automatisées, enclenchées au simple clic de l'utilisateur sur un bouton de formulaire. C'est pourquoi, nous proposons de mettre à jour le tarif d'un article, dont la référence doit être renseignée par l'utilisateur, au moment de l'exécution. Un critère dynamique doit être posé sur le champ produit_ref. Nous l'avions appris au travers des exercices sur les requêtes paramétrées, il s'agit de fournir une indication à l'utilisateur entre crochets. Access ne reconnaissant par le nom du champ mentionné, demandera de préciser l'information.

• Fermer la table Produits et fermer la requête R_MAJ_TS_Prix,
• Dans le volet des objets Access, cliquer droit sur la requête R_MAJ_TS_Prix,
• Dans le menu contextuel, choisir Mode création,

Comme vous le constatez, tous les champs ont disparu de la grille de requête, sauf le champ produit_prix de la mise à jour. Voilà pourquoi, nous l'avons volontairement fermée pour la rouvrir. Et justement, le critère pour la mise à jour doit être posé sur un autre champ. C'est en fonction de la référence désignée que le prix de l'enregistrement correspondant doit être actualisé.

• Dans la représentation de la table, double cliquer sur le champ produit_ref,

Nous l'ajoutons ainsi sur la grille de requête.

• Dans sa zone Critères, saisir l'expression suivante : [Référence à mettre à jour ?],

Voilà donc le paramètre dynamique de notre requête. Comme nous nous plaisons à le répéter, nous leurrons Access. Les crochets encadrent normalement un nom de champ. En guise de nom, nous fournissons une indication précieuse que la requête sera obligée de restituer à l'utilisateur.

• Enregistrer cette modification,
• Puis, cliquer sur le bouton Exécuter dans le ruban contextuel Créer,

Une boîte de message apparaît instantanément. Mais cette, fois il ne s'agit pas de l'avertissement comme précédemment, pas encore.



Il s'agit du fameux critère à préciser. C'est la raison pour laquelle cette boîte de dialogue offre une zone de saisie en guide de réponse.

• Taper par exemple la référence du premier article, soit : XXXX-2222,
• Puis, cliquer sur le bouton Ok pour exécuter la requête,

Cette fois, le message d'alerte, similaire au précédent, surgit. Mais comme vous pouvez le voir, l'action est désormais beaucoup plus limitée, grâce au critère qui a bien trouvé sa correspondance dans la table Produits. Access indique qu'une ligne va être modifiée. Cette remarque est importante. Si la référence saisie n'existe pas dans la table, cette requête n'altère aucun enregistrement.

• Cliquer sur le bouton Oui du message d'avertissement pour procéder,
• Puis, double cliquer sur la table Produits pour l'ouvrir,

En effet, le tarif du premier article a encore été majoré tandis que tous les autres n'ont pas bougé.

Avant d'aborder les autres types de requêtes action, nous souhaitons mettre à profit ces nouvelles connaissances pour corriger une anomalie. Nous l'avions évoquée lors des exercices précédents. Le champ produit_code de la table Produits devrait être renseigné pour tous les enregistrements. C'est loin d'être le cas pour l'instant. Seuls 5 des 245 articles sont actuellement associés à un code promotionnel. Ces codes sont archivés dans la table Remises. Ils varient de 1 à 9 et correspondent à des taux de réduction en pourcentage. Le premier, représenté par le chiffre 1, propose une remise de 0%. C'est donc lui que nous devons inscrire pour tous les enregistrements. Il sera amené à évoluer, pour des articles spécifiques, sur commandes enclenchées par les administrateurs depuis un formulaire. Mais nous n'en sommes pas encore là.

• Fermer la table Produits ainsi que la requête R_MAJ_TS_Prix,
• En haut de la fenêtre Access, cliquer sur l'onglet Créer pour activer son ruban,
• Dans sa section Requêtes, cliquer sur le bouton Création de requête,
• Dans la boîte de dialogue qui suit, désigner la table Produits,
• Puis, cliquer sur le bouton Ajouter et sur le bouton Fermer,
• Dans la représentation schématique de la table, double cliquer sur le champ produit_code,
• Dans le ruban contextuel Créer, cliquer sur le bouton Mise à jour,
• Dans la zone Mise à jour du champ produit_code, saisir le chiffre 1,

Le seul champ qui doit être effectivement actualisé est le champ produit_code. En l'absence de critère, tous les enregistrements sont concernés. Nous l'avons compris avec la première requête mise à jour de cet exercice.

• Enregistrer la requête (CTRL + S) sous le nom : R_MAJ_produit_code,
• Puis, dans le ruban contextuel Créer, cliquer sur le bouton Exécuter,

L'avertissement désormais classique surgit. Fort naturellement, Access informe que les 245 articles vont être impactés.

• Confirmer l'exécution de la requête mise à jour en cliquant sur le bouton Oui,
• Double cliquer sur la table Produits pour l'ouvrir en mode feuille de données.

Comme vous le constatez, la mise à jour a parfaitement fonctionné. Plus aucun code promotionnel ne manque. Ces requêtes action sont donc particulièrement précieuses et productives. Imaginez le temps qu'il aurait fallu manuellement pour actualiser chaque enregistrement. De fait, si nous exécutons la requête R_NC_prod_remises de non correspondance que nous avons bâtie dans l'exercice précédent, elle ne livre plus aucun résultat. En effet et désormais, chaque article est bien relié à la table Remises sur le champ produit_code. Inversement, si nous exécutons la requête équijointure R_produits_remises, elle restitue tous les enregistrements de la table Produits. Quand nous l'avions fabriquée, elle ne restituait que les quelques articles pour lesquels un code promotionnel était renseigné.

D'autres corrections sont à apporter dans notre base de données. C'est tout l'intérêt de ces requêtes action. Nous nettoyons et améliorons l'information de façon automatisée. Nous l'avions indiqué, dans la table Communes, tous les codes postaux inférieurs à 10000 ont été amputés du zéro en préfixe. Nous avions expliqué la raison. Ces données sont le fruit d'une importation réalisée depuis un classeur Excel. Et comme vous le savez, Excel gère des nombres. Par conséquent, il élimine les zéros en préfixe qu'il juge superflus. Mais un code postal est nécessairement codé sur 5 chiffres. Nous devons donc replacer ce chiffre zéro, lorsque le champ n'est codé que sur 4 chiffres. Le critère consiste à déceler les enregistrements pour lesquels la longueur de ce champ n'est que de 4 caractères. Et nous l'avions déjà exploitée, c'est la fonction Access NbCar qui retourne le nombre de caractères d'un champ.

• Fermer la table et la requête précédente,
• Dans le ruban Créer, cliquer sur le bouton Création de requête,
• Dans la boîte de dialogue, choisir la table Communes,
• Puis, cliquer sur le bouton Ajouter et sur le bouton Fermer,
• Dans le ruban Créer de la requête, cliquer sur le bouton Mise à jour pour la convertir,
• Dans la représentation de la table, double cliquer sur le champ Commune_dep,
• Dans sa zone Mise à jour, saisir l'expression suivante : '0' & [Commune_dep],

Ce champ est typé comme un texte. C'est ainsi que nous l'avions paramétré dans la table. Aucune opération numérique n'est en effet à prévoir sur des codes postaux. Nous concaténons le 0 en préfixe ('0') avec l'actuel contenu du champ ([Commune_dep]). Mais cette concaténation ne doit se produire que lorsque la taille du champ est insuffisante. Pour cela, nous devons ajouter une condition dans sa zone Critères.

• Cliquer avec le bouton droit de la souris dans sa zone Critères,
• Dans le menu contextuel, choisir Créer,

Ainsi et comme nous l'avons appris au travers des exercices, nous affichons le générateur d'expression.

• Dans la liste de gauche, déployer l'arborescence des fonctions jusqu'à sélectionner l'élément Fonctions intégrées,
• Dès lors, dans la liste du centre, sélectionner la catégorie Texte,
• De fait, dans la liste de droite, double cliquer sur la fonction NbCar,

Cette dernière s'inscrit dans la partie supérieure du générateur d'expression : NbCar(«string»). Nous devons remplacer son paramètre suggéré («string») par le nom du champ à tester, sans oublier la condition.

• Adapter l'expression comme suit : NbCar([Commune_dep])=4,

La mise à jour consistant à ajouter le zéro en préfixe ne doit désormais s'opérer que sous cette condition.

• Cliquer sur le bouton Ok du générateur pour valider l'expression,

De retour dans l'éditeur, vous notez sa syntaxe apparaître dans la zone Critères du champ, sous la zone de mise à jour.

• Enregistrer la requête (CTRL + S) sous le nom : R_MAJ_cp,
• Puis, cliquer sur le bouton Exécuter dans le ruban Créer,

Access informe que 620 lignes vont être modifiées. Souvenez-vous, la table Communes compte 1003 enregistrements.

• Valider en cliquant sur le bouton Oui,
• Puis, double cliquer sur la table Communes pour l'afficher en mode feuille de données,

Comme vous le constatez, tous les codes postaux codés à l'origine sur 4 chiffres ont été corrigés. Tous les autres, n'ont pas été impactés. Maintenant que les données de cette table sont conformes, notre requête R_MAJ_cp ne produira plus aucune modification. En effet, son critère ne peut plus trouver de correspondance.

• Fermer la table Communes ainsi que la requête R_MAJ_cp,

Nous venons de démontrer une fois de plus, l'intérêt crucial de ces requêtes action pour nettoyer et homogénéiser l'information. Mais ce n'est pas fini.

Requête suppression
Nous devons désormais nous intéresser aux requêtes permettant de supprimer des enregistrements. Ces dernières, mal exploitées, sont aussi dangereuses que la précédente, voire plus. Une fois les données supprimées, il n'est plus possible de les restaurer. Finalement, le principe de construction est semblable. Mais la nature de la requête change. Pour débuter, nous proposons de créer une requête permettant de supprimer un article, en fonction d'une référence à définir dynamiquement. Vous l'avez compris, sa condition d'action doit être un paramètre placé sur le champ produit_ref de la table Produits.

• Dans le ruban Créer, cliquer sur le bouton Création de requête,
• Dans la boîte de dialogue qui suit, choisir la table Produits,
• Puis, cliquer sur le bouton Ajouter et sur le bouton Fermer,
• Dans le ruban Créer de l'éditeur de requête, cliquer sur le bouton Suppression,

Nous venons de transformer la nature de la requête. Et à ce titre, vous notez l'apparition de la ligne Supprimer dans la grille de requête. Tout comme pour une requête Mise à jour, elle n'est pas destinée à livrer les résultats d'une extraction.



Cette requête doit agir sur les enregistrements de la table Produits. Donc seul le champ du critère est nécessaire, d'autant qu'aucune opération n'est engagée par une requête Suppression.

• Dans la représentation de la table, double cliquer sur le champ produit_ref,
• Dans sa zone Critères, taper une indication entre crochets : [Référence à supprimer ?],

Vous remarquez la présence de l'attribut Où dans la zone Supprimer. Il confirme, en cas de correspondance avec le critère, que la suppression sera bien enclenchée sur la table Produits citée juste au-dessus, dans la zone Table.

• Enregistrer la requête (CTRL + S) sous le nom : R_Suppr_ref,

Elle apparaît aussitôt dans le volet des objets Access. Elle est accompagnée d'une nouvelle icône très représentative et sans équivoque.

• Cliquer sur le bouton Exécuter dans le ruban contextuel Créer,

La boîte de dialogue de la requête action paramétrée se déclenche. Elle affiche le message personnalisé dans la zone de critère.

• Taper par exemple la référence du tout premier article : XXXX-2222,
• Puis, valider avec le bouton Ok,

Un message d'alerte surgit. Il avertit qu'un enregistrement est sur le point d'être éliminé. C'est très bon signe. Cela signifie que le critère dynamique a trouvé correspondance.

• Valider l'alerte en cliquant sur le bouton Oui,

Comme toujours désormais, nous sommes de retour sur l'éditeur de requête. Rien ne semble s'être produit. La requête a agi sur une table.

• Dans le volet des objets Access, double cliquer sur la table Produits,

Le premier enregistrement de la référence désignée a effectivement disparu. D'ailleurs, si vous consultez la barre de navigation en bas de la fenêtre, vous notez qu'il ne reste plus que 244 articles sur les 245 de départ. Notre requête Suppression est donc parfaitement fonctionnelle. Elle sera utile à l'avenir lorsque son exécution sera commandée au clic sur un bouton de formulaire.

Maintenant que nous connaissons le fonctionnement d'une requête Suppression, il est temps de passer aux choses sérieuses. Comme nous le disions, dans cet exercice, nous souhaitons les exploiter pour purger les données et corriger les anomalies. La table Communes présente un grand nombre de redondances. Il s'agit de les éliminer afin de conserver les enregistrements uniques sur la paire Commune_nom /Commune_dep. Le critère d'une telle requête semble particulièrement complexe à mettre en oeuvre. Mais dans l'exercice précédent, grâce à l'assistant, nous avons construit une requête capable d'isoler tous les doublons de cette table. Et désormais, nous savons comment la convertir pour la transformer en requête Suppression.

• Fermer la table Produits ainsi que la requête R_Suppr_ref,
• Dans le volet des objets Access, sélectionner la table Communes,
• La copier (CTRL + C) puis la coller (CTRL + V),
• A l'invite, la nommer Communes2 et valider par le bouton Ok,

On n'est jamais trop prudent. Nous allons engager des suppressions massives sur cette table. Il est préférable de conserver l'originale et d'agir sur la copie.

• Dans le volet des objets Access, cliquer droit sur la requête R_doublons_villes_cp,
• Dans le menu contextuel, choisir Mode création,

Nous basculons ainsi dans l'éditeur de requête. Vous remarquez la complexité et la longueur de la condition posée dans la zone Critères du champ Commune_nom :

In (SELECT [Commune_nom] FROM [Communes] As Tmp GROUP BY [Commune_nom],[Commune_dep] HAVING Count(*)>1   And [Commune_dep] = [Communes].[Commune_dep])

Il s'agit d'une requête SQL. Nous avons abordé ce langage dans l'un des exercices précédents.

• Dans le ruban Contextuel Créer, cliquer sur le bouton Suppression,

Le critère demeure et la zone Supprimer apparaît. La requête est bien convertie.

• Enregistrer les modifications (CTRL + S),
• Puis, cliquer sur le bouton Exécuter dans le ruban Créer,
• Valider le message d'avertissement en cliquant sur le bouton Oui,
• Puis, double cliquer sur la table Communes pour l'ouvrir,

L'opération de nettoyage semble s'être déroulée à merveille. Mais en y regardant de plus près, la suppression enclenchée est lourde de conséquence. Certes, nous avons supprimé toutes les répétitions. Mais les originaux ont été inclus dans l'opération. La ville d'Allauch apparaissait en double par exemple. Elle n'est plus présente du tout. La ville d'Aix en Provence apparaissait 6 fois avec 5 codes postaux explicitement différents. Il devrait donc en rester 5. Il n'en reste plus que 4. La requête sélection permettait en effet d'extraire les enregistrements en double mais affichait aussi l'enregistrement original. En la transformant en requête Suppression, nous avons enclencher l'élimination de tous les enregistrements présentant des répétitions. Nous avons donc bien fait de conserver une copie de la table.

Requête Ajout
La solution consiste à exploiter un autre type de requête action, la requête ajout. Elle doit insérer dans la table Communes, préalablement vidée, tous les enregistrements uniques, issus de la table Communes2. Et à l'occasion de la découverte du langage Sql, nous avions exploité la clause DISTINCT sur la paire de champs. Le résultat de l'extraction avait livré toutes les communes uniques, soit une vue purgée des répétitions, tout en conservant les originaux.

• Fermer la table Communes ainsi que la requête R_doublons_villes_cp,
• Dans le ruban Créer, cliquer sur le bouton Création de requête,
• Dans la boîte de dialogue, choisir la table Communes,
• Puis, cliquer sur le bouton Ajouter et sur le bouton Fermer,
• Dans le ruban Contextuel Créer de l'éditeur de requête, cliquer sur le bouton Suppression,
• Dans la représentation de la table, double cliquer sur le champ Commune_id,

Comme nous ne plaçons aucun critère, tous les enregistrements sont concernés. Donc, ils doivent tous être supprimés.

• Enregistrer la requête sous le nom : R_Suppr_ttes_communes,
• Cliquer alors sur le bouton Exécuter dans le ruban contextuel Créer,
• Valider le message d'avertissement avec le bouton Oui,
• Puis, dans le volet des objets Access, double cliquer sur la table Communes,

La table est effectivement complètement vidée. Nous constatons une fois de plus l'intérêt et la puissance de ces requêtes action. Désormais, nous pouvons y insérer tous les enregistrements uniques, issus de la copie Communes2.

• Fermer la table Communes ainsi que la requête R_Suppr_ttes_communes,
• Dans le volet des objets Access, cliquer droit sur la requête R_Communes_uniques,
• Dans le menu contextuel, choisir Mode création,

Nous basculons directement dans le mode Sql. Cette requête ne produit plus les résultats escomptés. A titre d'entraînement, nous avions testé certaines clauses du langage :

SELECT DISTINCT TOP 10 Commune_nom, Commune_dep FROM Communes WHERE Commune_dep LIKE '83*' ORDER BY Commune_dep DESC;

C'est la clause Distinct qui permet d'extraire tous les enregistrements uniques sur la paire de champs énumérés, soit Commune_nom et Commune_dep. La clause Top doit disparaître. Elle permet simplement de limiter la restitution aux 10 premiers enregistrements ici. Et nécessairement, la clause Where doit également disparaître. Elle émet une condition pour réaliser cette extraction des valeurs uniques, seulement sur le département du Var (83). Et bien entendu, c'est fondamental, la table à partir de laquelle la requête doit agir, devient la table Communes2 (From Communes2).

• En conséquence, adapter la syntaxe de la requête Sql comme suit :

SELECT DISTINCT Commune_nom, Commune_dep FROM Communes2 ORDER BY Commune_dep DESC;

• Enregistrer les modifications puis cliquer sur la croix de son onglet pour la fermer,
• Dans le ruban Créer, cliquer sur le bouton Création de requête,
• Dans la boîte de dialogue qui suit, activer l'onglet Requêtes,
• Sélectionner alors la requête R_Communes_uniques,

En effet, c'est bien le résultat de l'extraction des enregistrements uniques depuis la table Communes2 que nous souhaitons insérer dans la table Communes. Ainsi, nous obtiendrons bien la liste des villes purgées de leurs doublons tout en conservant l'enregistrement original.

• Cliquer sur le bouton Ajouter, puis sur le bouton Fermer,
• Dans le ruban contextuel Créer de l'éditeur de requête, cliquer sur le bouton Ajout,
• Dans la boîte de dialogue qui suit, désigner la table Communes avec la liste déroulante,

Une requête Ajout est nécessairement spécifique par rapport aux précédentes. Elle agit sur une table forcément différente de celle désignée comme source de données.

• Valider la boîte de dialogue avec le bouton Ok,
• Dans la représentation de la table, double cliquer sur les champs Commune_nom et Commune_dep, pour les ajouter sur la grille de requête,

Dans la zone Ajouter à, spécifique à cette requête, vous notez que l'ajustement est automatique. Les noms de champs sont en effet équivalents. La requête agit bien sur une copie de cette table qu'il s'agit désormais d'enrichir.

• Enregistrer la requête sous le nom : R_Ajout_Villes_uniques,
• Puis, cliquer sur le bouton Exécuter dans le ruban Créer,
• Valider le message d'avertissement et ouvrir la table Communes,

Elle compte désormais 845 communes sur les 1003 de départ. Si vous triez les enregistrements par ordre croissant sur le nom de la ville, vous retrouvez les communes sur lesquelles nous avions porté notre attention.



La ville d'Aix en Provence est listée à cinq reprises. Elle est à chaque fois associée à un code postal différent. La ville d'allauch réapparaît. Nous avons donc réussi à supprimer tous les doublons de la table tout en conservant les enregistrements originaux.