Discussion :

[guen]

Bonjour

Tout heureux de voir apparaitre les macro de données avec la version 2010, j'en ai usé (abusé ?) sur la centaine de table de mon projet pour historiser les modifications (créé_par/modifie_par et modifie_le) sur les évènements insert/update/delete. C'est génial...enfin, c'était génial... Avec des tables qui atteignent aujourd'hui plus de 100 000 lignes, quand je fais un update de toutes les lignes, cela prend un temps impossible !! Même si je le fais par une requête native d'access sans transaction (en principe plus rapide).
Il est vrai que je fais un appel à une fonction vba pour déterminer le nom de la personne actuellement connectée pour remplir modifie_le/par.
Avez-vous par hasard un système qui permet de désactiver temporairement les triggers d'une table ? (une petite propriété cachée de la table...please...)
J'ai pour le moment fait un système qui va d'abord lire dans une autre table qui répertorie le nom de toutes mes tables et indique si le trigger doit être appliqué ou pas. Si non, il abandonne là mais cette opération reste très longue également...
merci de votre aide

guen

[pyloupylou]

bonjour,

difficile de répondre comme ça.... quand tu parles de trigger peux tu préciser ce tu sous-entends
100 000 lignes n'est pas si énorme, je suppose que tes tables sont correctement indexées, as tu pu déterminer si c'étaient certaines requêtes qui posaient problèmes ou si c'est général ?
quelques pistes.... ( il y a un tuto bien fait sur performances http://loufab.developpez.com/tutorie.../optimisation/ ou la manière d'examiner le plan d'exécution est détaillé)
- les indexs, comme je te l'ai dis,
- éviter les appels aux fonctions vba directement dans tes select, si tu travailles par utilisateurs, essaye de factoriser l'utilisation de la fonction vba pour alimenter une variable temporaire qui sera ensuite reprise dans tes ordres de mise à jours
- travailler avec des requêtes qui minimisent les jointures, quitte à jouer avec un principe de table temporaires intermédiaires....

[guen]

bonjour

en fait, je parle bien du nouveau système de macro de données, l'équivalent des triggers dans les autres systèmes de base de données, pas des macros classiques d'Access (que je n'utilise jamais par ailleurs...) Il n'y a pas de requête derrière, juste un remplacement de la date de modification par la date du jour et une fonction qui va chercher l'utilisateur actuellement connecté pour mettre à jour le modifie_par/cree_par. J'ai l'impression de toute façon que, qu'importe ce que l'on mets dans la macro de données, sa simple existence rallenti grandement les opérations d'update/insert sur la table.

[accessisgood]

Tu cree un champ flag dans la table qui sera mis a "Yes" avant toute modification en masse par une operation exterieure (par exemple un query) sur une decision manuelle

En tout debut de macro BeforeChange et AfterUpdate tu fais un test du genre
---if Updated("flag") or flag=Yes then StopMacro--

[guen]

merci pour ta réponse. j'avais presque fait ça puisque en début de macro, il cherche dans une table de gestions des macros si les triggers sont activés pour cette tabl eou pas. si pas, alors, il quitte la macro. mais le simple fait de faire cette recherche de "flag" ralenti beaucoup les actions en masse sur la table... je pense que les "triggers" sous Access ne sont pas optimisés...

[marot_r]

Bonjour.

As-tu lu :
"Les bonnes pratiques de la programmation des macros de données"
http://warin.developpez.com/tutoriel...nements-table/

Il y est mentionné quelques chausses-trappes qui peuvent alourdir le traitement.

A+