Les nouveautés de Microsoft Access 2010

Tout d'abord, avant de se lancer à la création de la macro correspondante, il est nécessaire d'établir le chemin à emprunter. Il se compose de plusieurs étapes :

1. Mémoriser le numéro de la commande concernée
2. Parcourir toutes les lignes de tblDetailsCommande pour en mémoriser le prix
3. Faire le cumul de ces lignes
4. Rechercher l'enregistrement correspondant dans la table tblCommande
5. Mettre à jour le champ TotalCommande

Pour cela, Microsoft Access intègre un nouveau générateur de macro permettant de créer des blocs d'instructions régis par une condition ou bien encore une boucle. Ainsi le bloc ForEachRecord va permettre de parcourir les lignes d'une table, LookUpRecord de rechercher un enregistrement, etc.

Il est important de garder en tête que lorsque vous placez une instruction dans un bloc vous ne pouvez atteindre que les données issues de ce bloc. Cette notion est peu commune mais un exemple saura vous éclairer : en début d'une macro attribuée par exemple à la table tblDetailsCommande, si vous faites appel au champ [idCommande] c'est celui de la table tblDetailsCommande qui sera concerné, en revanche si vous ouvrez par la suite un bloc LookUpRecord recherchant une information dans la table tblCommande, tout appel à [IdCommande] dans ce bloc fera référence au champ [idcommande] de la table tblCommande. Etre vigilant à l'ordre des méthodes est donc primordial pour garantir que vous manipulez les bonnes données.

Pour créer le déclencheur, rendez-vous sur la table tblDetailsCommande en mode Création et éditez sa macro nommée After Insert (après insertion).

L'éditeur suivant s'affiche :

Comme nous l'avons indiqué dans la section précédente, la première étape consiste à mémoriser l'identifiant de la commande concernée. Pour cela, le générateur de macro intègre les LocalVar qui sont des variables permettant de stocker des données le temps de l'exécution de la macro. La méthode SetLocalVar permet d'en définir la valeur. Pour accéder à une variable mémorisée précédemment, il suffit de l'appeler par son nom, comme cela aurait été fait pour un champ. La variable recevant le numéro de commande sera nommée varIdCommande, elle sera donc accessible via la syntaxe : [varIdCommande]

Comme vous pouvez le constater sur l'image ci-dessus, il n'y a pas de syntaxe spéciale pour définir que vous faites référence à l'enregistrement en cours. En fait, dès que vous appelez un champ de la table porteuse du trigger, la valeur retournée correspond à celle disponible dans l'enregistrement qui vient de lever l'évènement.

Dans le but de stocker le montant total de la commande au cours du traitement, il est nécessaire de créer une nouvelle variable, nous la nommerons varCumul. Sa valeur sera fixée à 0 au début de l'exécution, de nouveau via SetLocalVar.

Afin de remplir cette variable de cumul, il est nécessaire ensuite de parcourir tous les enregistrements qui ont le même numéro de commande que celui en cours. La méthode ForEachRecord permet cela. Son premier argument représente la table à parcourir, le deuxième le critère de recherche servant à filtrer les données et enfin l'argument Alias est le nom avec lequel il sera possible de faire référence à l'enregistrement. Alias est un paramètre que l'on retrouve dans plusieurs blocs de macros. Bien que facultatif, comme pour toute variable, une déclaration ayant du sens ne peut que vous servir.

Pour chaque ligne trouvée par le bloc ForEachRecord nous allons mettre à jour la variable de cumul en faisant de nouveau appel à SetLocalVar. La nouvelle valeur sera : [varcumul]+qte*PrixUnitaire :

Etant donné qu'aucune action supplémentaire ne viendra s'inscrire dans le bloc ForEachRecord, il est conseillé de le replier en cliquant sur le sigle - à sa gauche afin de limiter les erreurs de saisie (il faut bien avouer, que pour l'instant, la saisie des macros est un peu décourageante)
La méthode LookUpRecord permet ensuite de rechercher la commande dans la table tblCommande. Le critère sera bien entendu basé sur la variable varIdCommande. Pour pouvoir éditer l'enregistrement retourné, il est nécessaire de faire appel au bloc EditRecord, un peu comme vous l'auriez fait avec la méthode Edit d'un recordset. Ici, l'Alias est vraiment important faute de quoi le moteur ne saura pas quel jeu de données vous voulez éditer. Pour terminer, la méthode SetField dans le bloc EditRecord permet de mettre à jour la valeur du champ TotalCommande pour l'enregistrement trouvé. La gestion par bloc d'instructions est un régal lorsque l'on imbrique les méthodes comme ici. En effet, celles-ci s'exécutent à la condition que le bloc soit opérationnel. En d'autres termes, et contrairement à VBA, le développeur n'a pas à s'affranchir des tests d'exécution tels que "l'enregistrement a été trouvé", "l'enregistrement est éditable ...

Il ne reste plus qu'à enregistrer et à tester. Le résultat est bien celui attendu puisque toute insertion dans la table tblDetailsCommande met à jour la table tblCommande. Bien entendu, pour être cohérent, il est nécessaire d'appliquer le même calcul sur les évènements After Update et After Delete.

Voilà une fonctionnalité qui a été longtemps dénoncée par son absence. Malheureusement, si la vue du bouton Create Table Events m'a vraiment réjoui, la découverte de la fonctionnalité me laisse un goût amer. Je ne pense pas que c'est à cela que pensaient ceux qui l'ont tant réclamée. Il faut se contenter de macro là où du code SQL aurait sûrement été plus pratique et plus performant. La volonté d'offrir les évènements sur table aux novices a pris le dessus même s'il s'agit d'un non-sens selon moi. Quel débutant sous Access se sent réellement concerné par les problèmes de triggers, contraintes, intégrités, etc. ? Cela aura au moins eu le mérite de me faire écrire ma première macro, et ce ne sera certainement pas la dernière tant cette fonctionnalité de triggers est importante.

N'hésitez pas à donner votre avis sur les nouvelles fonctionnalités d'Access 2010 : 21 commentaires