Discussion :

[mgascult]

Bonjour,

Je suis sur un nouveau projet mais avant de me lancer je souhaiterai vos conseils.

Cet outil sera bâti avec des formulaire dont les champs seront basés sur des variables afin de ne pas agir directement dans les tables.
Il me faudra donc à un moment donné récupérer des valeurs dans les tables et les « injecter » dans ces variables pour les modifier.

Le souhait des utilisateurs est d’avoir un historique sur tous les champs dont la valeur serait modifié afin de les conserver dans une table d’audit avec :
valeur précédente du champ, date/heure, user, nouvelle valeur du champs.

C’est complétement nouveau pour moi et vos lumières me seront précieuses sur la façon de procéder.

Je vous remercie et vous souhaite une belle journée.

[micniv]

Le souhait des utilisateurs est d’avoir un historique sur tous les champs dont la valeur serait modifié afin de les conserver dans une table d’audit avec :
valeur précédente du champ, date/heure, user, nouvelle valeur du champs.

Comme tu l'as écrit, ton outil sera constitué essentiellement d'une table historique qui comportera les colonnes suivantes :
. table du champ modifié
. nom du champ (dans la table) modifié
. valeur précédente
. nouvelle valeur
. date heure_modif
. user_modif

Dans l'appli existante, il convient d'abord de lister tous les champs qui sont à historiser.
Ensuite, il te faut modifier l'appli pour alimenter la table historique dès qu'un champ 'historisable' est modifié

Dans un second temps, tu étudieras comment tu veux exploiter cet historique.

Cordialement

[mgascult]

Merci micniv

grosso modo, il faut que je fasse des lignes de code pour chaque champs afin de vérifier si la valeur a changé et ensuite écrire la donnée dans la table d'audit puis inscrire la valeur dans la table principale?

[ilank]

Bonjour,

Oh la. Tout d'abord de quelle manière comptes-tu gérer la déconnexion de tes formulaires ?

[mgascult]

je ne sais pas encore

[mgascult]

pour le moment, j'ai presque terminé l'identification des champs et des tables et commencé à préparer la gestion des utilisateurs en me basant sur le tuto Denis HULO.
Une partie de mes relations est faite.

[hyperion13]

Salut
1 - Créer une copie de la tbl d'origine pour en faire une tbl d'archive
2 - Créer un form attaché à la tbl d'origine
3 - Pour tester une ou des modifs sur l'enregistrement en cours d'un form utiliser Private Sub Form_BeforeUpdate(Cancel As Integer), avec un If MsgBox("Voulez-vous enregistrer les modifications ?", vbQuestion + vbYesNo, "Enregistrer ?") = vbYes Then. Tu déroules 1 qry action (Insert into) qui va copier l'enregistrement en cours sans les modifs enregistrées (état initial) suivi d'un DoCmd.RunCommand acCmdSaveRecord qui lui enregistrera les modifs.
4 - Créer une qry UNION qui permettra quels sont les champs qui ont été modifiés en visualisant ancienne et nouvelle valeur.

[mgascult]

merci hyperion13,

C'est un peu complexe pour mon niveau mais je garde en mémoire et demanderai un peu d'aide si je sui coincé

[ilank]

Ok,

La déconnexion des formulaires implique que la consultation des données et l'enregistrement de leur modification sont dépendantes d'événements utilisateurs.
1) Un événement utilisateur provoque la recherche en base des données à afficher dans un formulaire
2) Un événement utilisateur provoque l'enregistrement des données modifiées

C'est lors de l'événement 2) que ton code peut générer l'historique.

Tu peux t'orienter vers l'emploi de tables temporaires ou envisager des modules de classe.

[mgascult]

merci ilank,

Je pensais "charger" mes variables dans le formulaire et au moment de l'enregistrement faire le contrôle de contenu de chaque champs avant d'inscrire les données modifiées dans la table Audit et ensuite remplacer la valeur dans la table originale.

Je ne suis pas encore familiarisé avec les modules de classe

[ilank]

Je pensais "charger" mes variables dans le formulaire et au moment de l'enregistrement faire le contrôle de contenu de chaque champs avant d'inscrire les données modifiées dans la table Audit et ensuite remplacer la valeur dans la table originale.

Oui, c'est ce qu'il faut faire, je pense.

Les modules de classe permettent de créer des types d'objets personnels. Ils permettent aussi de créer des événements personnels.

Je voulais demander un exemple mais ce n'est peut-être pas utile.

[mgascult]

merci ilank,

Je vais étudier le sujet et ferai un nouveau poste lorsque j'aurai un peu plus de matière pour donner des exemples.

Merci à tous, je vais fermer celui-ci et ouvrirai un nouveau le moment venu.
belle journée à tous

[ilank]

Bonjour,

oops je me suis trompé de verbe. Je voulais donner un exemple et pas demander.

[mgascult]

merci ilank,

Je veux bien

[EricDgn]

Bonjour,

Trois exemples trouvés sur l'internet: Tracking data changes in Access, A simple solution for tracking changes to Access data et celui qui me semble le plus intéressant Audit Trail using Data Macros vu qu'il observe directement les tables (et pas les formulaires). Si nécessaire, un bon traducteur: deepl.

Je conseillerais aussi de placer cette table de suivi dans un fichier séparé du reste car elle va vite devenir très importante. Il faudra aussi prévoir un dispositif d'élimination des données les plus anciennes.

Cordialement.

[mgascult]

Bonjour,

merci EricDgn, je vais regarder cela et traduire surtout mon anglais est piètre
Effectivement, je me pose la question de mettre l'audit dans une autre base avec juste une liaison avec la table.

[EricDgn]

Un tutoriel: Les bonnes pratiques de la programmation des macros de données.
Cordialement.

[mgascult]

merci, je vais étudier tout cela

[ilank]

Bonjour,

tous les exemples présentés sont intéressant mais s'appuient sur les événements de formulaire BeforeUpdate (avant mise à jour), AfterUpdate (après mise à jour), Dirty (sur modification). Ces événements ne sont levés que si le formulaire dispose d'une source de données. Or, mgascult a indiqué dans son premier post :

Cet outil sera bâti avec des formulaire dont les champs seront basés sur des variables afin de ne pas agir directement dans les tables.
Il me faudra donc à un moment donné récupérer des valeurs dans les tables et les « injecter » dans ces variables pour les modifier.

[mgascult]

effectivement, c'est la façon que j'envisage plutôt que de passer par une table temporaire.