Discussion :

[in]

Bonjour,

voilà c'est surement une question bete dont j'ai peur d'avoir la réponse ...

est-il possible de créer/dropper une table SQL à partir d'un QueryTable. Excel me dit que "la méthode ou propriété n'est pas gérée par l'objet" ...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
req_sql = "CREATE TABLE tmpCostDecomp AS " & _
          "SELECT wbs_id " & _
          "      ,proj_id " & _
          "      ,phase_id " & _
          "FROM admuser.projwbs " & _
          "WHERE delete_date IS NULL " & _
          "START WITH wbs_id IN(" & liste_baselines & ") " & _
          "CONNECT BY PRIOR wbs_id = parent_wbs_id"
 
Worksheets(Feuille_Data).QueryTables(Feuille_Data).CommandText = req_sql
Worksheets(Feuille_Data).QueryTables(Feuille_Data).Refresh BackgroundQuery:=False   'erreur ici

Y a t'il une techique qui me permette de passer outre le fait que de telles requetes ne retournent pas de résultats ?

A priori il faut que j'utilise ADO pour pouvoir faire ça ? et là je suis un peu (beaucoup) embêté ...

Le problème est que ce fichier excel doit être distribué à tous les utilisateurs. Or, cette distribution passe par la mise à jour de la seule feuille qui contient tout le code de mon application. Les gens qui possèdent une version de l'appli n'ont pas la référence à ADO dans leur appli.

Il va donc falloir que chaque user fasse l'ajout de la référence à ADO. Ce qui est impossible (selon le gars en charge de la migration) ...



Donc en résumé. Je cherche un moyen de pouvoir créer/dropper une table depuis Excel en utilisant que les trucs de base de vba ... Y a 'il une solution envisageable ?

[EDIT] s'il est possible de charger la référence à ADO par le code (sans que le user n'ai rien à faire) je suis preneur. a mon avis c'est ça la solution la plus simple ...

[dadavyvy]

Le problème est que ce fichier excel doit être distribué à tous les utilisateurs. Or, cette distribution passe par la mise à jour de la seule feuille qui contient tout le code de mon application. Les gens qui possèdent une version de l'appli n'ont pas la référence à ADO dans leur appli.
Il va donc falloir que chaque user fasse l'ajout de la référence à ADO. Ce qui est impossible (selon le gars en charge de la migration) ...
[EDIT] s'il est possible de charger la référence à ADO par le code (sans que le user n'ai rien à faire) je suis preneur. a mon avis c'est ça la solution la plus simple ...

Qu'entends-tu par charger la référence à ADO? le MDAC est-il installé sur les ordis?

1/ si oui, ton fichier n'a pas besoin d'avoir la référence cochée. Il suffit de ne pas déclarer tes variables comme des objets ADODB, et travailler comme si tu le faisais en VBscript, càd avec des CreateObject. Exemple :

Code :

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

Set aConn = CreateObject("ADODB.Connection")

Cet exemple est équivalent à

Code :

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

Dim aConn As New ADODB.Connection

sauf que le 1er code, n'a pas besoin d'avoir la référence activée

2/ si non, tu dois installer MDAC sur les ordis qui ne l'ont pas

3/ il est possible d'ajouter (activer) une référence par le code dans ton projet VBA : http://www.developpez.net/forums/sho...d.php?t=186566

[in]

Bon je regarde ça tout de suite. Par contre MDAC je ne connais pas mais mon ami Google va surement me fournir les explications nécessaires.

Merci en tous cas, je pensais que j'étais dans la mouise ...


[EDIT]

Bon alors MDAC je ne sais pas s'il est installé sur toutes les machines et vu que c'est pour le "groupe", il y a des chances que non

Pour ajouter la référence dans le code j'ai également le souci que je ne peux pas savoir quel est le chemin pour chaque poste. Il y a des entités qui utilisent citrix par exemple ... enfin bref autant de config que d'entités du groupe ...

Bref, je vais quand même tenté d'ajouter la référence ADO et on verra ce que me diront les gars chargés de la migration .... ils n'ont qu'à pas être en vacances

[in]

Ce que j'entends par charger la référence ADO c'est que la référence soit cochée dans la liste des références. enfin juste que je puisse utiliser une connexion ADO dans mes macros.

Quand tu parles de MDAC d'installé. C'est pas la référence dans VBA dont tu parles, c'est vraiment d'un autre outil microsoft ? en tous cas la référence n'est pas faite dans la classeur.

Mais maintenant je doute. Si je coche la référence à ADO et que je file mon fichier à quelqu'un d'autre, la référence est-elle conservée ou alors l'utilisateur doit créer cette référence lui-même ?

Désol", moi et le VBA ça fait 10 ...

[EDIT] Bon à priori MDAC est installé sur les machines qui utilise l'appli. Donc c'est parfait, ça fonctionne !

Merci bien

[dadavyvy]

Euh, oui.. ok... euh une autre question?... d'accord...
Bref, tu as tout compris par toi-même... cool! même pas eu le temp de te répondre.

MDAC n'est pas un outil Microsoft à part. En gros, il te rajoute les ActiveX nécessaires pour la gestion des connections entre bases de données : (MDAC = Microsoft Data ActiveX Component ~ DAO = Data ActiveX Object).

Si tu coches la case dans les références, tu verras qu'il existe plusieurs version de MDAC (2.5, 2.7, 2.8 etc...). Si tu coches une version que les autres ordis n'ont pas, ta macro ne tournera pas (la référence sera cochée mais marquée comme "MANQUANTE"). D'où l'intérêt de ne pas activer la référence, mais de travailler avec CreateObject, qui utilisera la dernière dll installée ou utilisée par défaut par le système (enfin je crois), car CreateObject ne fait pas intervenir la version : CreateObject("ADODB.Connection").

Ensuite, concernant le chemin de la référence dépendra donc de la version. Mais pour chaque version c'est en général le même chemin quelque soit l'ordi, s'ils ont le même système d'exploitation.