Historisation des saisies (vérification de code vba)

Version imprimable

Bonjour,

Je met en place un "historisation des saisie" sur access.

On travail que sur des forumaires et je voudrais mettre en place ce code :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
Option Compare Database
Public TempID, TempPhase, TempDate, TempUtilisateur 'déclaration public pour historisation, utilisable dans tous les modules
 
Public Sub Historique()
    'Historisation des données
    'utliser DAO pour remplir la table historique
    'L'ID doit être indéxé avec doublons et pas de clé primaire
    'Placer la table dans un autre fichier access ???
    Dim THistorique As Recordset
    Set THistorique = CurrentDb.OpenRecordset("T Historique", dbOpenDynaset)
    THistorique.AddNew
        THistorique![ID] = TempID
        THistorique![Phase] = TempPhase
        THistorique![DatePhase] = TempDate
        THistorique![Utilisateur] = TempUtilisateur
    THistorique.Update
    THistorique.Close
    Set THistorique = Nothing
    Set TempID = Nothing
    Set TempPhase = Nothing
    Set TempDate = Nothing
    Set TempUtilisateur = Nothing
End Sub
 
Sub TestHistorique()
    TempID = 16010
    TempPhase = "Début de chantier"
    TempDate = Now()
    TempUtilisateur = "DUPOND Jean"
    Call Historique
End Sub

Est-ce que ce code est viable sur le long terme ?

Dois-je placer la table sur un autre fichier access ? (je lie la table à mon fichier de travail)

J'accepte toutes les remarques sur la façon de "coder" :)

Merci d'avance pour vos réponses !

Bonjour,

Tout d'abord sur le code lui-même et au delà de toutes considérations fonctionnelles :

Toujours utiliser Option Explicit, il faut l'ajouter à la main après Option Compare pour les modules déjà présents et le régler dans VBE (outils/options/Editeur/Déclaration des variables obligatoires) pour l'ajout automatique dans les nouvelles créations.
Ainsi tu réduits le risque potentiel d'erreurs de nommage de 100%.

Ne jamais utiliser currentdb directement mais toujours au travers d'une variable typée. Certaines méthodes ne fonctionnent pas et niveau perfo/libération c'est une catastrophe.

Les variables globales : En effet lorsqu'on ne les type pas elles sont Variant par défaut. Cependant, attention à la méthode d'écriture "toutes les variables sur une seule ligne". Les variables se typent une à une et non ligne par ligne. Mais peut être le sais-tu déjà ?
Concernant le set Nothing sur un variant. Pourquoi pas, ce n'est pas habituel mais ça ne gène en rien. Sauf que... tu les perds définitivement après la première exécution, et ce n'est pas le but.
Personnellement je les aurais typé plus fortement. ID Long, TempPhase String ? et que ces 2. On y reviendra plus loin.

Concernant le choix d'une procédure au lieu d'une fonction. Il faut savoir que la fonction, à la différence de la procédure, peut être directement incluse, du moment qu'elle est publique et dans un module standard, dans la propriété de l'évènement de ton choix (Après MAJ ?), comme un nom de macro ou le réglage [Procédure Evenementielle].
Cela peut faciliter et accélérer grandement la mise en place dans tous les formulaires.

Concernant la question, "placer la table dans une base séparée" oui ! sans hésiter. Ce montage a le défaut de faire prendre un rapide embonpoints à une base.

Concernant les valeurs :
Pourquoi choisir des variables globales et pourquoi autant ?
Pour le user cela se justifie mais le reste peut être passé en paramètres ou n'est pas sujet à modification. TempDate par exemple : c'est toujours la date (et l'heure) du jour pourquoi la mettre en variable ? Date() ou Now() feront l'affaire.

Voici une nouvelle écriture possible :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public vgUtilisateur as string public function setHistorique(tempId as long, tempPhase as string) dim db as dao.database Dim THistorique As dao.Recordset set db = currentdb Set THistorique = db.OpenRecordset("T Historique", dbOpenDynaset) THistorique.AddNew THistorique![ID] = TempID THistorique![Phase] = TempPhase THistorique![DatePhase] = now() THistorique![Utilisateur] = vgUtilisateur THistorique.Update THistorique.Close db.close set THistorique = Nothing set db = Nothing end function
L'appel dans la propriété se fait avec la syntaxe des expressions d'IHM :

Code:

=setHistorique(formulaires.[NomForm].[NomId], "Phase")

Une autre approche consiste à utiliser le Screen.activeForm pour s'affranchir des paramètres mais cela nécessite un champ ID uniformisé et de également de s'occuper de Phase.

Cordialement,

10/02/2016, 09h13
BaRJo05

Bonjour,

Tout d'abord je prends bonne note de vos conseils concernant Option Explicit, la mise en variable typée de currentdb et la déclaration des variables.

Concernant

Citation:

L'appel dans la propriété ce fait avec la syntaxe des expressions d'IHM :

faut il que je note directement

Code:

=setHistorique(formulaires.[NomForm].[NomId], "Phase")

sur la feuille de propriété à la place de "Procédure évènementielle" ? Si c'est le cas, vous venez de me faire découvrir une chose bien pratique.

Je reste donc sur mon idée de placer la table sur un autre fichier :)

En tout cas, merci pour votre réponse vraiment complète !
10/02/2016, 09h34
loufab

il fallait lire :

Citation:

L'appel dans la propriété se fait avec la syntaxe des expressions d'IHM :

Oui c'est bien cela.
On peut même utiliser la multisélection (sélection de +sieurs contrôles) pour renseigner chaque propriété en une seule passe. Cependant, dans ton cas (1 par formulaire) ça n'a aucune utilité.
10/02/2016, 10h49
BaRJo05

Un grand merci à toi, après test çà fonctionne à merveille !