Discussion :

[Bamban]

Bonjour,

Je suis actuellement sur un problème assez dur à cibler, donc je vais commencer par poster ici, dans le doute.

Voila, j'utilise des tables liées (odbc) avec access 2007 pour faire des requêtes tous les jours. Suite à un changement des tables liées (que je ne gère pas du tout) j'ai du changer mes requêtes. Pour faire simple, une table assez conséquente avec de nombreux champs à été séparé en trois (trois fois moins de champs dans les 3 tables). La conséquence, c'est que j'ai du ajouter des joints dans toutes mes requêtes pour ajouter les informations qui m'étaient nécessaires. L'ajout pur et simple des tables manquantes donnait une requête qui se terminait en 6h. Moui, pas très efficace professionnellement.

Je suis passé par plusieurs étapes. De l'ajout du joint bête à l'optimisation de requêtes etc. Je ne rentrerais pas dans le détail car j'ai l'impression que ma requête SQL en elle même ne pose pas (ou plus) de problèmes.

Voici le coeur du problème : j'allume mon PC, je lance ma bdd access puis la requête (appelons la par son nom, reportingV6). Access m'ouvre une fenêtre qui dit :

Vous allez exécuter une requête Création de table qui modifiera les données de votre table
Etes-vous sur.......

Au moment ou je pousse le bouton "oui", access se met à ramer et 30 minutes plus tard, me demande si je souhaite vraiment supprimer la table existante, et dans la foulée me demande les infos de connexions à la bdd distante (login, mdp). Puis viennent 30 seconde d’exécution du SQL et jsuis rendu.

J'ai déjà essayé de supprimer la table avant de lancer la requête, et même de lancer une autre requête depuis le même fichier access (pour qu'il ne me demande plus les infos de connexions qui restent valables tant qu'on ne ferme pas le fichier) et rien n'y fait. Le plus rageant est que, si je relance cette requête, il me demande les mêmes informations (sauf la connexion donc, vu que c'est la seconde fois que je lance une requête dans ce fichier) immédiatement et exécute la requête en une minute.

Je précise que la première fois, après la seconde vague d'information (à t+30min), la barre d'avancement se réveille et file à toute vitesse, pour terminer la requête 30 secondes plus tard. C'est le même chrono qu'au seconde lancement.

Voila, je ne comprend donc pas pourquoi au premier lancement ce cette requête, access met tant de temps à démarrer. Car j'ai vraiment le sentiment que le problème ne vient pas de mon code SQL, et que c'est un mic mac made in access qui fait que le processus global et ralenti, et pas l’exécution propre du code. Je peux vous dire qu'après quelques jours d'optimisation de requête, j'ai la rage (en plus je n'ai jamais vraiment eu de formation SQL/access, donc je patauge)

Dernière précision, j'ai plusieurs champs calculés en VBA. Test réalisé sans ces champs => même résultats.

Quelqu'un peut-il éclairer ma lanterne ?

Ps : je ne fournis pas le code SQL pour la simple et bonne raison qu'il est confidentiel (enfin j'imagine) et aussi parce que mes recherches s'orientent plus sur un problème au niveau de access pur.

[Richard_35]

Bonjour Bamban,

.../... et dans la foulée me demande les infos de connexions à la bdd distante (login, mdp) .../...

==> cela me paraît curieux. Quand tu lies des tables via ODBC, la fenêtre de choix de la table te demande "Enregistrer le mot de passe" : il faut cocher cette case pour ne pas avoir à rentrer le login/mdp à l'ouverture des tables.

.../... je ne fournis pas le code SQL pour la simple et bonne raison qu'il est confidentiel .../...

==> je ne vois pas en quoi un code SQL peut-être confidentiel. Les données affichées, OK, mais le code SQL ?...
Si le nom des tables/champs lui-même est confidentiel, il suffit de les renommer xx, yy, etc...

[Bamban]

Quand tu lies des tables via ODBC, la fenêtre de choix de la table te demande "Enregistrer le mot de passe

Parfaitement d'accord, j'ai recrée la base avec ceci. Bien sur, l'expérience que j'avais mené m'avait déjà informé que le problème ne se situait pas là.

je ne vois pas en quoi un code SQL peut-être confidentiel.

En fait, mon code est crade. Je ne code pas directement en SQL mais je réalise les requêtes avec l'outil graphique de access. Donc c'est pas indenté. Ajoute que j'ai de nombreuses requêtes imbriquées et tu finis par n'avoir que 20% de l'information en ayant le code SQL.

[Richard_35]

l'expérience que j'avais mené m'avait déjà informé que le problème ne se situait pas là

==> dans ton expérience, le login de connexion t'était-il également demandé ?


Plusieurs pistes, peut-être :

• Vérifies les nouvelles jointures que tu as dû créer suite au découpage de ta table ;
• Il faudrait que tu remettes ton code SQL dans l'assistant en sauvegardant la requête, puis éliminer, une à une, les tables qui te semblent en cause et repérer le moment où ta requête se déroule normalement.

[Bamban]

En fait, le login/mdp n'est demandé qu'une fois par instance de fichier. Donc pour tester la solution "sans avoir à taper le mot de passe", je lançais une autre requête courte, qui me demandait le login, et qui faisait que je n'avais plus besoin de l'entrer pour ma grosse requête.

Tests faits, j'ai ajouté l'enregistrement du mot de passe et ça n'a malheureusement rien changé.

Bon, je me lance sur tes pistes. Merci pour le coup de pouce !