Les évènements de table

bonsoir à tous,

l’année 2011 est maintenant bien avancée, cela fait déjà plus d’un an qu’Access 2010 est sortie avec son lot d’améliorations et de nouveautés (le backstage, les macros, la MFC, les champs calculés, le générateur d’expressions, les évènements de table,…).

Sans pour autant renier ou dénigrer les autres nouveautés, la possibilité d’implanter des évènements de table (les triggers à la sauce Access) m’est apparue dans un premier temps comme LA nouveauté de la mouture 2010.
http://img862.imageshack.us/img862/5549/trigger1.png

Voir Les bonnes pratiques de la programmation des macros de données

Citation:

---

Envoyé par Christophe Warin

Les évènements de table introduits avec Microsoft Access 2010 permettent de mettre en place la quasi-totalité des traitements qu'il est possible de faire subir à un jeu de données. Ils peuvent être utilisés pour valider la saisie de l'utilisateur … ou bien pour transposer la saisie dans une autre structure en y appliquant des règles de gestion jusque-là confiées à VBA via un formulaire.

---

Enfin c’est ce qu’il me semblait, je voyais déjà venir une flopée de discussions sur la programmation d’évènements de table avec des macros de données sur nos forums:aie:… et puis en fait rien ou presque…:?

Je mets donc en place ce petit sondage pour en connaître les raisons.

Votre opinion sur le sujet est la bienvenue… même si vous n’êtes pas utilisateur d’Access 2010.

Citation:

---

Concernant la programmation des évènements de table avec les macros de données (dataMacro) je fais partie de la catégorie suivante:

Récalcitrant : je n’utiliserais jamais les évènements de table car je pense qu’ils sont peu fiables voire inutiles.

Averti : Je connais bien cette nouvelle fonctionnalité et j’en tire profit.

Prudent/Attentiste : J’ai entendu parler de cette nouveauté mais j’ai besoin de parfaire mes connaissances avant de l’utiliser dans un cadre professionnel.

Non-utilisateur d’Access 2010 : je n’utilise pas Access 2010 ou/et j’ai besoin de conserver la compatibilité avec les versions précédentes…bouhhh.

Novice : c’est quoi un trigueurre ??

Autre catégorie : précisez laquelle…

---

Bonjour

Effectivement, cette évolution semble peu utilisée pour l'instant, déjà pas par moi, car je n'utilise pas la version 2010 au TAF :aie:.

Je pense que les membres qui n'utilisent qu'Access n'ont pas une vue large sur ce sujet, mais ceux qui ont utilisés des bases de données qui acceptent les triggers en voient un intérêt non négligeable.

Donc en résumant, c'est pour moi un manque de connaissances du sujet.

Philippe

salut Philippe:coucou:,

Citation:

---

Envoyé par Philippe JOCHMANS

... car je n'utilise pas la version 2010 au TAF :aie:.

---

C’est certainement la raison principale, les discussions avec le tag [AC-2010] ne sont pas si fréquentes à ce jour.

Et puis comme tu l’indique bien, celui qui n’a jamais pratiqué un SGBDR Client/Serveur comme SQL Server, Oracle, MySQL … avec des triggers programmés côté Serveur, ne verra pas de raison majeure à programmer des datamacro avec Access. D’autant plus que les macros Access n’ont pas forcément bonne presse comparées au VBA:?.

Pourtant, on peut y trouver de nombreux avantages pour assurer l’intégrité des données et là c’est Tofalu qui a montré la voie avec ses tutoriels:

- Numérotation personnalisée

- Création d’un journal d’évènements


et puis pêle-mêle par ma propre expérience:

- Validation de données résultants de contraintes de gestions complexes

http://www.developpez.net/forums/d10...evenemnt-leve/

http://blog.developpez.com/f-leb/p96...avec-les-even/

- Maintenance d’un champ calculé redondant évitant des traitements complexes

http://www.developpez.net/forums/d1007119/logiciels/microsoft-office/access/contribuez/demo-gestion-stock-evenements-table/

bon, ça viendra peut-être avec le temps, patience8-)…

Bonjour,

Personnellement, j'aurais souhaité utiliser les événements de tables disponibles dans Access 2010. Je pense que c'est plus efficace que les événements de formulaires, du moins dans certains cas . Mais comme entre 2 maux il faut choisir le moindre, je préfère sacrifier cette fonctionnalité pour ne pas perdre la sécurité niveau utilisateurs que m'offre Access 2003 et que je ne retrouve pas dans les versions postérieurs.
C'est pareil pour les autres fonctionnalités apportées par Access 2007 comme les pièces jointes, les champs calculés...
Espérons qu'un jour Microsoft se ravisera et sortira un Access qui reprenne tout ce qu'il y'a de bien dans les versions antérieures

Cordialement

Face à un tel succès (merci d'arrêter de voter afin de ne pas surcharger les serveurs:mrgreen:), je me suis senti obligé de revenir à la charge:aie:.

Je persiste et signe et vais même plus loin,

et pourquoi pas un nouveau sous-forum Access:

Citation:

---

[Macro Access] le forum dédié aux questions relatives aux macros Access.

---

d'abord...

Salut Fabien,

On va en discuter en équipe, mais de prime abord, l'idée est intéressante.

Merci à toi.

A bientôt,

Bonsoir

L’idée est effectivement très intéressante.
Ce forum sera d'une grande utilité pour les débutants en programmation notamment ceux qui souhaitent s’entraîner sur un langage simple comme les macros avant de passer au VBA.

Cordialement

Ouaah ! la foule !
Avec la pêche industrielle, il doit plus rester le moindre maquereau de données (pardon)
Sérieux : j'ai plussé Reedy, un peu pour la gestion des droits (sur mdb) mais surtout, parce que les versions, comme toujours, ne sont pas décidées par nous, mais par nos clients. Ça devient acrobatique de faire des logiciels compatibles 2000 -> 2010, mais ça marche sans trop d'anicroches !

Par contre, oui, c'est bien évidemment une excellente avancée. Pardon, une très très bonne avancée. Je réserve le terme d'excellence pour le jour où on programmera les macros de données en VBA (je sais, je sais, mais peut encore rêver, non ?)

Salut Etienne ;)

Pour ce qui est du VBA en lieu et place des macros de données, je pense effectivement que c'est un doux beau rêve, puisque cela obligerait MS soit à mettre un interpréteur de VB du côté du moteur de données, soit à compiler le code au moment de la validation, ce qui me semble complexe. Par contre, offrir la possibilité d'écrire le déclencheur en sql, ce serait chouette. Surtout que je pense que la macro est traduite en SQL côté du moteur de données. Mais bon, l'interface de saisie des macros de la 2010 a quand même été amélioré, donc, perso, j'applaudis MS à ce sujet.

Pour ce qui est de la problématique des versions, au risque de polluer un peu de débat initié par Fabien, dans la mesure où l'on livre une appli qui ne doit pas être modifiée par le client, le problème peut être résolu par l'installation du runtime, et l'on peut alors travailler avec l'interface 2010 sur une base MDB, conciliant ainsi les avancées d'interface d'un ACCDE avec la sécurité utilisateurs (et la compatibilité avec les logiciels tiers) au niveau du fichier de données MDB, qu'un client pourrait toujours "attaquer" avec un développement en MDB s'il le souhaite et s'il a la licence. Ok que cela ferait un peu "usine à gaz", mais cela permet de développer un tronc commun de logiciel que le client final complète par une appli à sa sauce en ACCDE, MDE ou MDB, voire même via une autre techno, du VBA Excel, etc.

Elle est belle, quand même, la vie avec Access, non?

Bonne semaine!

Bon giorno, Pierre,

Tout à fait d'accord : :ccool:

Citation:

---

Envoyé par Pierre Fauconnier

Pour ce qui est du VBA en lieu et place des macros de données, je pense effectivement que c'est un doux beau rêve, puisque cela obligerait MS soit à mettre un interpréteur de VB du côté du moteur de données, soit à compiler le code au moment de la validation, ce qui me semble complexe. Par contre, offrir la possibilité d'écrire le déclencheur en sql, ce serait chouette. Surtout que je pense que la macro est traduite en SQL côté du moteur de données. Mais bon, l'interface de saisie des macros de la 2010 a quand même été amélioré, donc, perso, j'applaudis MS à ce sujet.

---

Pas du tout d'accord : :aie:

Citation:

---

Envoyé par Pierre Fauconnier

Pour ce qui est de la problématique des versions, au risque de polluer un peu de débat initié par Fabien, dans la mesure où l'on livre une appli qui ne doit pas être modifiée par le client, le problème peut être résolu par l'installation du runtime, et l'on peut alors travailler avec l'interface 2010 sur une base MDB, conciliant ainsi les avancées d'interface d'un ACCDE avec la sécurité utilisateurs (et la compatibilité avec les logiciels tiers) au niveau du fichier de données MDB, qu'un client pourrait toujours "attaquer" avec un développement en MDB s'il le souhaite et s'il a la licence. Ok que cela ferait un peu "usine à gaz", mais cela permet de développer un tronc commun de logiciel que le client final complète par une appli à sa sauce en ACCDE, MDE ou MDB, voire même via une autre techno, du VBA Excel, etc.

---

Je relève plusieurs points qui ne collent pas avec diverses expériences :
1- Il y a longtemps qu'à part des applications vraiment simples, je n'utilise plus aucun runtime, ni même de .mdE (ou accdE) compilé : trop de choses qui ne fonctionnent plus, en particulier dès que l'application a besoin d'ouvrir un objet (form, report) en mode Design (remettre l'orientation des états, enregistrer la disposition d'une feuille de données...).

2- L'interface ACCDB n'a plus aucune protection. C'est le + souvent elle qu'on veut protéger. Pour la base de données contenant les tables, les utilisateurs doivent toujours pouvoir saisir, modifier, supprimer des données + avoir la main sur la structure des tables attachées, dans le frontal, juste pour permettre de ré-attacher les tables externes. Voir l'utilisation de WITHOWNERACCESS, dans les cas extrêmes, qui n'est pas lié à la "protection" des mdb.

3- un frontal ACCDB sur une dorsale MDB ? À tester soigneusement !
Perso, jamais testé, mais je crois que je n'oserais pas. J'ai essayé une librairie .MDB avec un frontal .ACCDB, et je garantis la catastrophe totale : à prescrire absolument.
OK, pour la dorsale, ce n'est pas une question de compatibilité entre compilateurs VBA. Mais les compilateurs ACCDB et MDB sont censés être rigoureusement identiques, non ? Et ils ne marchent pas ensemble.
Est-ce que quelqu'un en a fait l'expérience ?

Tout à fait d'accord : :ccool:

Citation:

---

Envoyé par Pierre Fauconnier

Elle est belle, quand même, la vie avec Access, non?

---

Bonjour à Tous,

Il semble qu'il y a autant de façons d'utiliser access que d'utilisateurs 8O

Citation:

---

Envoyé par Papy Turbo

3- un frontal ACCDB/E sur une dorsale MDB ? À tester soigneusement !

---

D'après ma modeste expérience cela fait partie des trucs qui marchent assez naturellement :)

Pour revenir au sondage j'utilise encore Access 2000 pour sa grande compatibilité ascendante. Cela fait plus d'un an que j'envisage de passer à Access 2007 mais cela me pose des problèmes avec des utilisateurs office 2000 + XP... Donc Access 2010 pour moi c'est pas avant 2020 :aie:

En fait ma prochaine version aura probablement une base PostGre, sur laquelle je porterai les plus gros traitements en PL/SQL afin d'alléger les postes clients. Tout ça pour dire que pour moi, la grosse évolution serait d'avoir un équivalent du PL/SQL sur la dorsale. Est-ce le but de ces "triggers" ?

Salut Nicolas,

Citation:

---

Envoyé par nico84

[...]
Tout ça pour dire que pour moi, la grosse évolution serait d'avoir un équivalent du PL/SQL sur la dorsale. Est-ce le but de ces "triggers" ?

---

Oui et non.

Non, car même placé sur la dorsale, c'est quand même le client qui fait le boulot. Le réseau n'est donc pas soulagé par ce travail et les triggers n'ont pas transformé le moteur de données en serveur. Donc, pour soulager les postes clients, il faut alors travailler en se connectant sur un vrai serveur de données. Access peut le faire nativement avec SQL Server au travers d'un projet Access. Le client peut alors être soulagé par certaines opérations effectuées sur le serveur.

Oui, car le déport sur le moteur de données de traitements grâce aux "triggers" que sont les macros de données permettent de sortir les traitements faits sur l'appli par du vba et de les imposer à tous les clients qui se connectent sur la base. C'est d'ailleurs ce qui explique que les macros de données, comme les clauses de validation par exemple, ne peuvent utiliser que des "outils" natifs du moteur de données, à l'exclusion donc de fonctions perso en VBA ou de manipulations de l'interface (formulaires, par exemple). Cela étant, il manque effectivement à Access la possibilité de créer des procédures et fonctions stockées même si, dans certains cas, des requêtes sur le dorsal MDB peuvent pallier à ce manque.

Bonsoir Etienne,

1. Ok pour les limitations sur les ACCDE et MDE. Perso, je dirais que c'est cela que j'aime bien car je suis comme cela certain qu'on ne modifie pas mon appli. Donner la main à la modification d'un formulaire pour qu'on te sucre le contrôle dont ton code VBA extrait une donnée, c'est quand même loin d'être le top. En général, je déporte les formulaires et états personnalisés par le client sur un fichier distinct, mon appli se chargeant de les rapatrier et le ruban leur donne accès via un combo aux éléments qu'ils ont eux-mêmes créés. Pour la reliaison des tables, je le propose dans le ruban et cela fonctionne bien.

2. Justement, si on a besoin d'une base de données sécurisées, on reste en MDB et on travaille avec un workspace sécurisé. Ainsi, le accde est protégé par sa nature même, et le mdb contenant les bases est protégé par le workspace et les groupes/utilisateurs. Evidemment, cela nécessite que l'on ose le point 3.

3. Il n'y a aucun problème à utiliser un frontal 2010 sur une base de données MDB. Perso, je ne rencontre aucun blocage et je bénéficie de l'interface 2010 qui est tout de même plus convivial. Evidemment, cela nécessite de ne pas devoir utiliser les nouveautés 2010 côté moteur de données (macros de données, champs multivalués, ...). Pour les macros de données, c'est un peu dommage. Pour les champs multivalués, ce n'est pas une grande perte. Perso, je déteste ces champs et je préfère de loin passer par la structure classique de liaisons m:n.

Comme le dit Nicolas, à chaque utilisateur son Access...

Citation:

---

Envoyé par f-leb

et pourquoi pas un nouveau sous-forum Access:

Citation:

---

[Macro Access] le forum dédié aux questions relatives aux macros Access.

---

d'abord...

---

eh ben le voilà:ccool:, le coin m'a l'air très sympathique en plus, faut que j'y trouve un truc à poster vite vite...

Vous voyez, quand vous voulez...:bravo:

C'est une bonne idée que de consacrer un forum rien que pour les macros en Access. D'ailleurs, je suis à la recherche d'un grand livre, s'il existe, qui ne parle que des macros avec Access.
Fockas.

Pourquoi les macros de données sont si peu utilisées ?

Je pense que c'est surtout du fait des choix de MS. Access est de plus en plus orienté vers le non-développeur. Les contraintes d'intégrités référentielles sont déjà pas leur tasse de thé. Alors, les macros de données, validation et calculs dans la structure, pensez donc...

Comme je l'avais écrit dans une review sur la béta (cela commence à dater), il y a un grand risque pour le débutant que l'adoption des nouveautés masque le vrai problème : un modèle relationnel bancal qui transforme très vite l'application et sa base de données en véritable usine à gaz.

En 2005, Richard McAniff (à l'époque Corporate Vice-Président Microsoft Office) disait grosso modo :

Citation:

---

JET N’EST PAS MORT ! Et Microsoft investit dans la poursuite du développement d’Access

---

Mais entre temps, il y a eu sharepoint et l'envol du cloud.

Sharepoint et .Net pour les pros et Access pour les autres.

Ok, mais quid des autres pros ? Ceux qui développent en interne ou ceux dont les clients n'ont pas les moyens ni les besoins d'une artillerie lourde. C'est aussi sans compter les délais de livraison. Dès le modèle validé, une appli Access peut être livrée par brique très rapidement. Malheureusement, ceux-là ont été écartés.