Discussion :

[sylv20]

Petite question :

Vaut il mieux réaliser ses requetes sous access (avec l'éditeur graphique) ou direct en SQL dans VBA ?

Avantages et inconvénients des deux méthodes ?

[marot_r]

Personnelement je trouve qu'écrire les requêtes avec l'éditeur permet de les écrire plus vite (Access s'occupe de la syntaxe) et de les contrôler plus facilement puisqu'on peut voir le résultat immédiatement.

Et une requête est visible si elle est dans la liste des requêtes ce qui, je trouve, facilite le débuggage.

Au niveau performance, en théorie une requête en VBA est moins performante qu'une requête enregistrée car Access ne peut pas l'optimiser avant son exécution.

À l'usage je n'ai pas constaté de différence notoire.

Appeler une requête en VBA qu'elle soit enregistrée ou dans le code n'est pas très différent et ne nécessite pas d'effort majeur.

Personnellement je n'utilise le SQL dans le VBA que pour :

1. le vidage des tables (DELETE * FROM MaTable)
2. les requêtes de sélection où la clause where est dynamique
3. l'éditeur de requête ne permet pas de faire cette requête (très rare !)

Le reste du temps je refuse d'être privé du confort de l'éditeur de requête qui permet en quelques glisser/déplacer de réaliser des requêtes extrèment complexes (ex : Une table et 15 autres tables en jointure = 1/2h de travail avec les vérifications).

A+

[sylv20]

Ce que je trouve embettant c'est d'avoir tout un tas de requete dans la liste. On s'y retrouve moins bien, c'est le bazarre.

En effet ca a tous les avantages du graphique : rapidité et simplicité.

Et tu prefere le VBA ou l'aditeur de macro access ?

Ce que j'apprécie dans le vba c'est de pouvoir tout y mettre (macro, requete + code etc...)

[Invité]

Bonjour
Chacun a sa philosophie.
Pour ma part elles sont pratiquement toutes écrites en vba (même si je m'aide du Qbe). Comme cela elles sont créées dynamiquement en fonction des besoins, puis supprimées.
Les puristes de la performance crieront que ce n'est pas top, mais j'y vois un gros avantage: Même si quelqu'un bidouille une requête elle sera recréée telle qu'elle a été conçue...

[marot_r]

Et tu prefere le VBA ou l'aditeur de macro access ?

Je préfère le QBE mais comme le dit GAYOT , c'est aussi un point de vue personnel. Je lis assez mal le SQL donc pour comprendre une requête, généralement, je la colle dans le QBE et je la regarde graphiquement.

Et pour avoir fait de la rétro ingénieurie sur des bases, le SQL dans le code, je ne trouves pas cela exitant du tout.

J'ai aussi une vue un peu ségrégationniste sur le sujet : le SQL c'est pour les requête, le VBA c'est pour le code et si je peux quand je parle à une autre BD (ex : Oracle) j'utilise des procédure stockées qui encapsulent complètement la complexité des requêtes ou modules appellés.

Pour ce qui est de la liste, je suis d'accord avec toi, ça peut devenir rapidement confus. La solution que j'ai adoptée est d'avoir une politique de nommage rigoureuse de manière a repérer rapidement ce qui m'interresse. Note qu'avec 2003 et suivante on peut créer des groupes d'objets qui peuvent faciliter l'organisation des tes éléments. J'ai, par exemple, fait un groupe démarage où je mets mon formulaire de démarage et éventuellement ma macro AutoExec.

A+

[f-leb]

Bonsoir,

Je ne retrouve plus la source Microsoft qui parle de ça mais de mémoire, les requêtes enregistrées à partir du QBE sont compilées à la première exécution (et recompilée à l’exécution seulement si la requête est modifiée ou la base compactée). La compilation consomme un peu de temps mais une fois compilée, l’exécution est en principe plus rapide.

Or il me semble que si la requête n’est pas enregistrée à partir du QBE mais rédigée dynamiquement à partir de VBA, la requête sera systématiquement compilée avant d’être exécutée.

A confirmer, ça me semble quand même bien théorique…

[Nitromard]

Bonjour à tous,

J'ai eu des cours sur du SQL pendant ma dernière année de master et j'ai maintenant plutot (voir un peu trop) l'habitude de les taper à la main avant d'essayer de les faire fonctionner et ça me permet aussi de voir où il pourrait y avoir un problème, si problème il y a.

Donc pour moi le mieux c'est de les taper directement...
Mais ayant déjà utilisé l'éditeur graphique, je trouve qu'il peut apporter de l'aide qd on s'y connait pas trop, enfin c'est l'impression que j'ai.