Création triggers par programmation

Version imprimable

16/05/2014, 11h52
Bowen

Création triggers par programmation
Bonjour,

J'ai besoin de journaler des modifications dans certaines de mes tables access 2013 (accdb).
Pour ça, je créée des triggers dans ma BDD access.
J'ai bien trouvé comment le faire par l'interface d'access :
- Ouvrir une table
- En haut, onglet table
- Bouton "après maj"
- "Créer un enregistrement dans une table"
- Puis là, je remplis une table journal avec le nom de ma table (constante) et la valeur de ma clé.
J'ai ainsi la liste des lignes modifiées, ce que je veux.

MAIS !
Je veux maintenant créer ces triggers par programmation... et là je bloque.
Je ne trouve pas l'objet qu'il faut utiliser.

Quelqu'un le connaît ?
16/05/2014, 14h17
PipoWIL

Bonjour,
Je ne suis pas familier de ce sujet, mais si je peux faire une proposition, je wous conseillerais de regarder du cote de SQL. Ne pouvez-vous pas, en VBA, executer un statement SQL qui va modifier votre table ?
Il m'arrive de faire des

Code:

application.currentdb.execute "ALTER TABLE [MaTable] ALTER COLUMN MonChamp Currency"

Ne peut-on envisager un statement semblable pour un trigger ?

Ceci peut-il aider ==> http://msdn.microsoft.com/en-us/library/ms189799.aspx
16/05/2014, 14h35
Bowen

Non, la syntaxe create trigger ne marche pas dans access.
Je n'ai pas le choix, il faut passer par la programmation vba.

Les objets doivent exister, mais je n'ai pas encore trouvé ce que c'est...

Bonjour,
Personellement, je n'ai pas de trigger dans Access 2007, mais voici comment je ferais :
etape 1
Trouver le nom (avec l'orthographe précise) de la propriete "Trigger" :

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
Function essai_Ajout_Trigger()
Dim db As DAO.Database
Dim T1 As DAO.TableDef
Dim F1 As DAO.Field                 'the fields of the t1 tables
Dim i As Integer
 
 
Set db = DBEngine.Workspaces(0).Databases(0)
 
 
For Each T1 In db.TableDefs
    If T1.Name = "Martine au parc" Then
        For Each F1 In T1.Fields
            Debug.Print F1.Name, F1.Attributes
            If F1.Name = "Jour" Then
                Debug.Print F1.Properties.Count
                For i = 0 To F1.Properties.Count - 1
                    Debug.Print i, F1.Properties(i).Name
                Next i
            End If
        Next F1
    End If
Next T1
set db = nothing
end function

Voir dans la fenetre debug si il il y a queque chose qui pourrait peut-etre convenir.

etape 2 :
si une propriete semble donner un espoir de chance, verifier avec ceci :

Code:

1
2
3
4
5
6
 
Dim p As Property
 
Debug.Print "f1.Properties('Trigger').Value =", F1.Properties("Trigger").Value         'en supposant que la propriete s'appelle "trigger"
Set p = F1.CreateProperty("Trigger", dbText, "Ce trigger est ajouté en VBA")       'à modifier...
F1.Properties.Append p

17/05/2014, 14h24
micniv

Bonjour ,
Regarde l'article de Christophe Warin

http://warin.developpez.com/tutoriel...s2010/journal/

:D
19/05/2014, 18h16
Tofalu

Bonjour

A ma connaissance, ce n'est pas possible en VBA, en tout cas pas avec des objets comme DAO. Peut-être en inscrivant les données xml ou brutes directement dans une table système, mais cela n'est pas du tout documenté. Je n'ai rien trouvé à l'époque à ce sujet :?
20/05/2014, 11h09
Bowen

@ PipoWIL : Bonne méthode (parcours VBA). Testé, sur les properties du champ et celles de la table, mais rien obtenu d’intéressant.
@ micniv : effectivement, cet article et l'autre qui y est référencé (premier lien) décrivent très bien comment faire un trigger... par l'interface graphique. Mais je n'ai rien vu sur la création par VBA.
@ Tofalu : Oui, j'ai bien peur que tu aies raison. Je ne vois de moyen d'accès par le code nulle part.

Je laisse le post en non résolu, mais j'ai bien peur que ça s'arrête là.
Question subsidiaire pour ceux qui ont utilisé les triggers :
Que faisaient vos triggers et avez-vous senti un ralentissement de la base en les mettant ?
20/05/2014, 20h24
Tofalu

Bonjour

Quelque soit le SGBD utilisé, les triggers ralentissent les insertions et les mises à jour. Mais dans des bases où la majorité des traitements sont de la consultation et du calcul, il est préférable de ralentir l'écriture que la lecture. Tout le monde préférerait mettre deux fois plus de temps pour faire le plein de sa voiture et mettre deux fois moins de temps pour faire le tour de Paris.

Après, tout dépend aussi ce qui est fait dans la macro de données. Les boucles de parcours d'enregistrements sont longues, c'est pour cela qu'il faut limiter les données à parcourir dans une requête bien construite. Quitte à lister tous les clients qui habitent Paris, autant n'interroger que ceux de Paris. Il faut aussi faire attention à la récursivité : http://warin.developpez.com/tutoriel...nements-table/