Discussion :

[LostIN]

Bonjour

selon vous, y a t'il une différence de rapidité entre une requete (sans paramètre) QBE et la même requete executé par le code ?
Si oui, pourquoi?
Comment utiliser les indexs pour les selections selon les deux méthodes avec access?

merci

[Trini]

Voir FAQ http://access.developpez.com/faq/?page=SQL#PerfReq

[LostIN]

Si la requête utilise des critères basés sur des champs indexés, alors mieux vaut passer par une requete et OpenQuery.

Docmd.Runsql ne fait qu'exécuter une instruction sql tandis que OpenQuery exécute une requête enregistrée (bénéficiant de la technologie Rushmore). Cette technologie est notamment basée sur l'usage des index pour la recherche d'un enregistrement. Ces index sont stockés dans une structure cachée.
Lorsque la requête s'exécute, si les critères sont posés sur des champs indexés, la requête peut être optimisée car la recherche se fait sur la structure des index et non directement sur la table.

ca manque de certitude.

La requete peut etre
d'où ma question.

[Petogaz]

salut,

cela va dépendre aussi dans tous les cas du volume de données traitées et des champs (champs indexés) sur lesquels va être basé ta recherche. enfin le mieux est de tester non ? ça te donnera la certitude que tu recherches.

[LostIN]

oui bien sur, le test sera le plus approprié pour mon cas.

Mais bon. On fait et on constate.
Je préfèrerais agir selon les spécifications propres, plutot que de laisser des suppositions.

On reste dans l'a peu près.
Du coup, selon la config, celà est performant, sinon l'inverse.

[Tofalu]

Tu poses une question, on te donne la réponse. Les requêtes enregistrées bénéficient de l'effet rushmore qui optimise l'utilisation des index, donc les temps de traitement. Il est donc clair qu'une requête enregistrée est plus rapide qu'une requête codée dans le VBA.

[LostIN]

très bien
dans ce cas, il serait judicieux de modifier le

Lorsque la requête s'exécute, si les critères sont posés sur des champs indexés, la requête peut être optimisée car la recherche se fait sur la structure des index et non directement sur la table.

Par un

Lorsque la requête s'exécute, si les critères sont posés sur des champs indexés, la requête SERA optimisée car la recherche se fait sur la structure des index et non directement sur la table.

Sinon on peut se poser la question du
Peut être, peut être pas?

Voila après tu peux donner des conseils à certains, en affirmant que cette technique est préconisée par rapport à l'autre. (ex: un prof)
car une réponse, qui induit, ca dépend des cas, contribue à dire qu'Access est un outil qui parfois est hasardeux, donc non pro.
Certains penseront que je chipote. Mais c'est justement après avoir vu cette remarque dans la FAQ que j'ai posté.

[=JBO=]

Bonjour,

[...] une réponse, qui induit, ca dépend des cas, contribue à dire qu'Access est un outil qui parfois est hasardeux, donc non pro.

Il ne faut pas tout mélanger: le fonctionnement du moteur de bases de données Jet n'a rien à voir avec le hasard.

Ici, ce qui fait défaut ce sont des "certitudes", qui pourraient se matérialiser, par exemple, sous forme de spécifications.
Ou encore, avec un livre qui traiterait du sujet...

En voici justement un, disponible en librairie (?) et aussi sous forme électronique dans la version MSDN fournie avec le pack développeur d'Office 2000 (ODE) et probablement avec les versions suivantes (?):

"Microsoft Jet Database Engine Programmer’s Guide".
Auteurs: Dan Haught et Jim Ferguson

[...] une réponse, qui induit, ca dépend des cas, contribue à dire qu'Access est un outil qui parfois est hasardeux, donc non pro.

Dans tous les cas, le contenu de la citation ci-dessus est "non pro" .


Pour en revenir à ce livre écrit par les concepteurs de Jet et à cet élément de la FAQ Access sur développez.com.

Microsoft Jet Query Engine Overview

The Microsoft Jet database engine contains a sophisticated query processor that’s responsible for query execution. There is, however, much more to the query engine than just a query processor. The query engine also contains a sophisticated query optimizer that takes any given query as its input and determines the fastest join strategy for executing that query.

A query may be internally optimized to yield a more efficient join strategy, but this is all done without intervention from the user. The goal of the query engine is to take any query, no matter how poorly structured, and execute that query in the most efficient manner.

En fait, toutes les requêtes soumises à Jet font l'objet d'une analyse et d'une optimisation: la phase d'analyse/optimisation peut être assez complexe et prendre du temps, mais a été optimisée (depuis Access 97 qui utilise Jet 3.5).

Faster Generation of Query Plans

In Microsoft Jet 3.5, the query plan generation process has been optimized to improve performance of temporary queries (for example, dbs.Execute SQL statement) and frequent modifications of stored queries in code.

Mais, dans le cas d'une requête stockée (alias requête Access), le résultat de cette analyse/optimisation est conservé avec la requête, pour être utilisé immédiatement à la prochaine exécution de cette requête: c'est ici que Jet gagne du temps.

En revanche, pour une requête créée à l'exécution, cette phase d'analyse/optimisation doit toujours être réalisée avant l'exécution.

Voilà, juste une petite contribution pour faire avancer notre savoir collectif .

[LostIN]

merci de cette contribution

car la faq n'est pas parole d'évangile.

[LostIN]

dans le même style

juste par curiosité car je ne fais et ne ferais jamais de macro.
Est ce qu'une macro est plus performante que son équivalent en code?

[=JBO=]

car la faq n'est pas parole d'évangile.

Un "Saint Thomas d'Access", qui ne croit que ce qu'il voit , nous propose un benchmark sur le sujet...

Article: Do Stored Queries Increase the Speed of Access Queries?
Auteur: Marcus Tucker
http://www.15seconds.com/issue/020919.htm

[LostIN]

un saint thomas d'access, je vais devoir changer de pseudo!!
si j'ai le temps, alors oui.