date de modification d'une donnée dans la base [Trucs & Astuces]

[Lucator]

Bonjour a tous
Avant tout, je vous pris de m'escusez ^^ je n'ai jamais appris a developper sous vb, ni utilisé access, j'essais d'apprendre tout seul, et ce n'est pas toujours simples, meme avec les nombreux tutorial :p voila mon probleme :

j'ai une table access, avec par exemple les champs nom, prenom, adress et un compteur Numéauto. j'aimerais rajouter un champs date, qui rajouterais automatiquement la date ( voir l'heure ) a laquel, on a crée la ligne dans la table ^^
je ne sais pas si c'est trés claire :p en gros je veut savoir quand a été modifier ou crée la ligne dans une table
si vous avez une idée, je suis preneur

** retourne chercher sur les forums **

[Demco]

j'aimerais rajouter un champs date, qui rajouterais automatiquement la date ( voir l'heure ) a laquel, on a crée la ligne dans la table ^^

Ajoutes donc un champ date a ta table.
Mets valeur par default: Now()
Je pense que ca suffire.

En esperant t'aider.

[guigui5931]

Ton formuliaire est lié à une table?
Si c'est le cas ce que tu peut faire c'est créer un champs texte dont tu met la proprété visible à Non. Tu lie ce champs à ton champs date de ta tableTu fait afficher dans ce champs le date du jour.
C'est un peu du bricolage mais si qulqu'un a mieux je suis preneur


Edit : trop tard et moins bon en plus

[Demco]

Apres relecture je ne pense pas que ma solution prenne en compte le fait que l'enregistrement ait ete modifié. La date sera toujours celle de la creation de l'enregistrement me semble-t-il. A tester !

[Lucator]

merci de vos réponses ci rapite je teste ca, et je vous informe si je trouve mieux pour pouvoir aider d'autres personnes

[random]

en fait pour gérer les modifs avec tracabilité il faut
copier la donnée avant modif ou après ajout dans une table historique avec un champ dateheure mis à now()
puis modifier la donnée dans la table de gestion

[Demco]

Envoyé par random

en fait pour gérer les modifs avec tracabilité il faut
copier la donnée avant modif ou ajout dans une table historique avec un champ dateheure mis à now()
puis modifier la donnée dans la table de gestion ou l'ajouter

Hop, encore un truc que je rajouterai a la FAQ, tu me gates aujourd'hui.

[ESVBA]

Mettre dans :
Form_BeforUpdate() tu sauves la date de la derniere modification
Form_BeforeInsert() tu sauve la date de création de l'enregistrement

Code :

1
2
3
4
5
6
7
8
 
Sub Form_BeforeUpdate()
   ChampdDateTimeLAstModif = Now()
End Sub
 
Sub Form_BeforeInsert()
   ChampdDateTimeCreate = Now()
End Sub

ChampDateHeure au format général 25/06/2007 12:45:45

[Papy Turbo]

ESBVA, bonjour et désolé, je sais que ce n'est qu'un détail, mais les bons évènements sont _Afterupdate ou _AfterInsert.
Les évènements BEFORE ne devraient être utilisés que pour valider la modification ou l'ajout d'un enregistrement -> si tout va bien, les paramètres Cancel de ces évènements (que tu as oublié dans ton code ) restent à False, sinon à True.
S'il n'y a pas besoin de Cancel, on n'utilise pas ces évènements.

En utilisant les évènements AFTER, on sait que
- le nouvel enregistrement a bien été ajouté,
- la modification a été enregistrée sans problème

Donc, à remplacer par

Code :

1
2
3
4
5
6
7
Sub Form_AfterUpdate()
   ChampdDateTimeLAstModif = Now()
End Sub
 
Sub Form_AfterInsert()
   ChampdDateTimeCreate = Now()
End Sub

Random : je ne vois pas pourquoi tu parles d'une table historique ?
On utilise souvent (surtout sur les grosses bases client/serveur) une date de création + une date de mise à jour et même, très souvent une date de fin (de validité...): l'enregistrement n'est plus valide, il n'apparaîtra plus dans les formulaires, mais on ne veut ou ne peut pas le supprimer, pour des raisons
- d'archivage et de statistiques
- d'intégrité référentielle
Par contre, tous ces champs sont directement dans la table, avec les données concernées. Ça me paraît plus simple.

Enfin, suggestion du pinailleur de service : en cas de mutli-utilisateur, on ajoute généralement le nom ou le code de l'utilisateur.
Si ton appli est protégée, chaque utilisateur tape son code et son mot de passe au démarrage.
Dans ce cas, tu peux ajouter 2 champs supplémentaires dans toutes tes tables :

Code :

1
2
3
4
5
6
7
8
9
Sub Form_AfterUpdate()
   LastUpdateDateTime = Now()
   LastUpdateBy = CurrentUser
End Sub
 
Sub Form_AfterInsert()
   CreatedDateTime = Now()
   CreatedBy = CurrentUser
End Sub

Enfin, si ces 4 champs sont affichés en petit, tout en bas de chaque fiche (en mode formulaire), on peut savoir parqui et quand a été créé, puis modifié chaque enregistrement (assez fréquent sur bases partagées...).

[random]

Papy Turbo
Pourquoi conserver les données antérieures dans une table historique ?

Habituellement comme tu le soulignes on stocke les données dans la table même avec leurs dates de validité, c’est un exemple parfait pour la tracabilité des tarifs (code produit,date début,date fin, tarif).

Maintenant soit un système d’informations nécessitant 50 champs pour lequel je veux pouvoir disposer non seulement des enregistrements mais de leurs modifications (tracabilité totale sur 10 ans), sachant que le coût de la tracabilité doit être le moins élevé possible en termes de performances.

Cout d’une modification 51 champs (50 de base + 1 champ horodatage )
Calcul d’une modif comparaison 50 champ
Si pourcentage 0.5% par an et par champ
Taille base après 10 ans 0.5%*50*10/2=+125%


Organisation en table historique
La table de base est toujours la table à jour
Dans la table histo je loge clef,horodatage,numchamp, exvaleur soit 4 informations
Après 10 ans ma table de base a des performances constantes taille identique
Ma base historique (séparée)
Contient
4*0.5%*10*50/50=20 % de la table de base
gain 105%
d’autre part la tracabilité se décline item par item et ne nécessite pas de calcul d’ensemble

[Papy Turbo]

yaisse !
Le temps de cliquer sur 'Envoyer', je me suis dit que tu voulais probablement une trace totale.

Je rappelle juste que la question de départ était :

Envoyé par Lucator

j'aimerais rajouter un champs date, qui rajouterais automatiquement la date ( voir l'heure ) a laquel, on a crée la ligne dans la table

donc, j'en suis resté à une simple date par enregistrement, sans distinction du ou des champs modifiés.

Ce qui est assez courant, alors que la trace totale répond à d'autres besoins.
Pour ma part, jamais eu ce genre de demande (trace complète) sous Access, mais je fais des logs de mise à jour, lorsque la saisie est déportée dans Excel par exemple : au moment de l'import depuis les classeurs vers la base de données, le journal (fichier texte) enregistre toute modif, champ par champ, + création d'enregistrement, et surtout les erreurs, oeuf corse.

Ben, ça pourrait être un bon sujet pour une petite contribution aux sources de DVP, ça, non ? Un exemple de table historique qui trace tous les ajouts + suppressions + toute modif, champ par champ... (Si tu es vraiment vicieux, une commande pourrait défaire puis refaire ces modifs, une par une, comme un Undo/Redo, non ? mais bon, j'exagère toujours un peu, juste pour rire )

[javelot69]

Bonjour,

Personnellement je suis intéressé si quelqu'un veut développer une contribution aux sources de DVP sur le sujet de la tracabilité (ou historique des modifications) car j'ai jamais eu (ou pris) le temps de me pencher sur ce sujet.

Donc pas un forcément un truc tout fait mais une contribution adaptable aux besoins des visiteurs serait génial.

Bonne soirée.

[ESVBA]

Papy Turbo

oui je suis d'accord en théorie sur Form_After***
mais je me souviens d'un problème...

mais en pratique, je viens d'essayer sous access 97.
Il m'affiche bien la date de création.
Mais pour la date de modification à chaque demande de changement d'enregistrement, il me réactualise la date alors que je n'ai fais aucune modification et en plus refuse de changer d'enregistrement !


Il n'y a dans mon formulaire que les deux procédures.
Si je place mon cod dans les Form_Before*** alors cela fonctionne !

Ai-je oublié qqc ?

[Papy Turbo]

Et pan dans la g.... !

Evidemment, le fait de modifier la date modifie l'enregistrement, donc il faudrait l'enregistrer à nouveau, ce qui est absurde.
Et voilà comment on peut dire de grosses c... sans tester, et sans même vérifier les bons vieux codes qui font cela.

C'est toi qui a raison : Before et non pas After

Donc, 2 bonnes raisons d'utiliser les évènements Before et non pas After :
1- tout ce qui a besoin d'utiliser Cancel (validations...)
2- tout ce qui modifie un champ quelconque du même enregistrement.

[coyot]

Salut

Le plus grand problème de la tracabilité n’est pas au niveau stockage de donnée mais de exploitation des données stocker

Il peut y’avoir deux type de modification (saisie, métier)

Saisie = c'est pour les erreur de saisie que l’utilisateur veut corriger, dans ce cas l’archivage est facultatif

Métier = c'est une procédure de modification l’archivage est indispensable

Je vais poser une question simple :

Un utilisateur veut voir les données telles que il était dans une date donnée X
Comment votre solution va réagir ?!!

Plusieurs problèmes ce pose :

1- on se retrouver avec de la récursivité des modification
2- on doit trouver les enregistrement dont la
Date = MAX(Date) < X (pour un jeux de clé donnée)
---> Le dire simplement à SQL (je ne sais pas le faire)

3- l’archive et une référence des traitements donc souvent solicitée
( la valeur de donnée a la situation n , depend de celle de la situation n-1 )

4- en peut toujours saisir des modification métier dans le mauvais ordre, le system doit pouvoir les réordonnée et refaire ses calcule tout seul
5- le cas des suppressions
6- recupiration de la situation actuel

C’est un véritable casse tête. Que j'aimerais bien résoudre avec votre aide

[Papy Turbo]

Salut, Coyot

attention quand même à ne pas monter une usine à gaz pour se chauffer une tasse de thé !

Je crois que la 1ère étape d'une analyse de ce type consiste à déterminer ce qu'on attend vraiment de ce type de traçabilité.
Selon mon expérience, tous les cas de saisie sous Access, du fait qu'ils concernent peu de personnes (5 au max. env.) sont très heureux de simplement savoir qui et quand a modifié un enregistrement (date et UserID de la création + dernière modif + clôture de l'enregistrement).
Pas d'enregistrement des anciennes valeurs.

Sur des bases client/serveur lourdes, j'ai vu des équipes aller plus loin, avec conservation du journal de transactions, pour tout retrouver.
Mais, là encore, les besoins de recherche, en cas de problème, étaient suffisamment rares pour que
- on ne conçoive, au départ, rien de particulier pour retrouver les bonnes données,
- lors du 1er incident, création manuelle des quelques requêtes pour retrouver les modifications et les anciennes données,
- au fur et à mesure des nouveaux incidents, seulement, automatisation progressive de cette procédure (qui, je suis d'accord, peut être très complexe).

À l'inverse, de nombreux comptables, par exemple, font simplement de bons backups :
- 1 jeu de sauvegarde par jour de semaine, du lundi au vendredi (soit 5 jeux)
- 4 jeux de sauvegarde hebdomadaires, (tous les vendredis soir ou lundis matin)
- 12 jeux de sauvegarde mensuels,
- 1 archivage complet par an (voire 2 ou 4, si on publie un bilan tous les semestres/trimestres...).

Ça leur permet de revenir en arrière de 1 à 5 jours, ou de 1 à 4 semaines, etc.
Aucune procédure informatique là dedans (sauf la sauvegarde , mais c'est pas du développement, alors pas drôle !)

[Tofalu]

Envoyé par Papy Turbo

Et pan dans la g.... !

Evidemment, le fait de modifier la date modifie l'enregistrement, donc il faudrait l'enregistrer à nouveau, ce qui est absurde.
Et voilà comment on peut dire de grosses c... sans tester, et sans même vérifier les bons vieux codes qui font cela.

C'est toi qui a raison : Before et non pas After

Donc, 2 bonnes raisons d'utiliser les évènements Before et non pas After :
1- tout ce qui a besoin d'utiliser Cancel (validations...)
2- tout ce qui modifie un champ quelconque du même enregistrement.

Mouais, sauf qu'ici on ne saura pas si l'enregistrement a été correctement modifié ou pas. Cas d'un verrou par exemple.

Peut être plutot utiliser AfterUpdate mais plutot que de modifier les données depuis le formulaire, le faire directement avec un ordre DAO

[cafeine]

En de vieux temps, j'avais tenté une approche :
http://cafeine.developpez.com/access/tutoriel/update/

[coyot]

Bonjour

Pour les "incident" je ne suis pas d'accords avec cette approche (ou bien j'ai mal compris)

A ne pas oublier que je parle de la tracabilité comme besoin métier non pas technique. L’utilisateur doit voir l'évolution d'un élément sur un axe des temps


Les solutions :
1- la recopie de l'élément
Problème : l'espace (recopie de grand enregistrement,
Recopie des éléments de relation 1- n)
2- une table historique
Problème : complexité des traitement (je n'arrive même pas a imaginer comment avoir un élément et ses sous élément a une date )

[Devipir]

Je reprends ce vieux post parce que cherche une solution pour enregistrer les dates de mise à jour d'un enregistrement à bas niveau, c'est à dire sans passer par des formulaires contenant les procédures BeforeUpdate .

L'idée est que si je modifie des données directement dans la table, ma date de mise à jour est ... mise à jour dès que l'enregistrement est validé.