Discussion :

[charliejo]

Bonjour,
J'ai réalisé un compactage sur ma base de données, j'ai eu 2 enregistrements crées dans la table MSysCompactError. Depuis, j'ai une requête qui met 2 fois plus de temps à s'exécuter.
J'ai créer une nouvelle base et copier toutes les tables, recrée mes relations, c'est encore lent. Je ne comprends pas bien cela devrait être l'inverse, plus rapide après.
Qu'est-ce qui a pu se passer?
Merci de m'aider, c'est vraiment bloquant, j'ai une fonction qui passe de 30sec à 3min à cause de cet requête (que j'execute plusieurs fois) qui a ralenti....

[marot_r]

Etonnant en effet.

Quels étaient les messages dans MSysCompactError ?

Est-ce que ta requête est une requête enregistrée ou une requête créer dans le code ?

Si tu es en mode Frontale (base qui contient le code)/Dorsale (Base qui ne contient que les données), as-tu aussi essayé de compacter ta base 'données' ?

Enfin tu peux essayer l'analyseur d'Access qui regarde ta BD et fais des suggestion d'amélioration de performance.

A+

[charliejo]

Merci pour votre réponse.
Je suis en mode frontale/dorsale. Mais j'ai testé en créant ma requête directement dans la base des tables. Avant compactage ma requête prend 2sec après elle en prend 3.
Ensuite elle est en fait exécuter dans le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
sql = "SELECT ...."
Set enreg = db.OpenRecordset(sql)

Et la en debugage, je vois également que la requête est plus longue.

L'erreur de compactage est -1017 "Impossible de trouver le champ « Description ».". Cela me supprime 2 enregistrements dans ma table. (Soit dit en passant, cette erreur de suppression d'enregistrement sur compactage ne m'était pas arrivé depuis au moins 4 ans, c'est vraiment étrange!!!)

Suggestion de performance, rien à signaler.

Il y aurait-il une sorte de cache qui fait que avant compactage ma requête était plus rapide?

[marot_r]

Oui, il y a un mécanisme qui détermine le plan d'exécution. Access détermine lors de la 1ère exécution comment il va faire la requête. Et ce plan est recalculé seulement à la 1ère exécution après un compactage.

Mais pour les requêtes créées par code généralement c'est le pire scénario qui est utilisé et le temps varie peut.

Sauf si ta requête change énormément je te suggère de la faire dans l'éditeur de requête et de l'essayer comme cela. Voit si cela fait une différence. De plus l'analyseur de performance ne peut pas évaluer le SQL dans le code donc tu pourrais peut-être le refaire avec la requête présente, il aura peut-être des suggestions d'amélioration.

A+

[charliejo]

Merci de votre réponse.
Ma requête contenait plusieurs tables avec sur une table un critère "comme '*a'", c'est cela qui faisait ralentir la requête. En faisant une première requête avec ce critère et en l'appelant dans une 2ème requête, le temps d'exécution est plus rapide. J'ai donc opté pour cette solution.
Cependant, je ne comprends toujours pas pourquoi c'est plus lent après compactage, cela aurait dû être lent dès le départ dans ce cas.... c'est vraiment étrange.
Ayant beaucoup de requête dans cette base, j'espère que cela n'en impactera pas d'autres....
Une idée pour expliquer le ralentissement dû aux critère "*a"?
Je vous remercie.

[marot_r]

Une idée pour expliquer le ralentissement dû aux critère "*a"?

L'instruction Like (ou Commme) empèche l'utilisation des indexs et donc il fait une lecture séquentielle, c-à-d qu'il commence au 1er enr et passe au suivant jsuqu'à ce qu'il ai touver ce qu'il cherche, de ta table pour trouver les données, c'est en principe le pire moyen de trouver de l'information.

Ceci dit c'est la première fois que je vois une chose pareille, comme tu l'as dis c'est généralement lent dès le départ.

Si tu veux vraiment comprendre pourquoi, il y a un moyen, assez complexe, de faire afficher le plan d'exécution de Access. Fait une recherche dans google sur Microsoft Access Execution Plan et tu devrais trouver comment faire.

A+