création d'une requête SQL directe en VBA

Version imprimable

Bonjour

Je voudrais créer une requête SQL directe en VBA, paramétrer sa connection, pour pouvoir s'en servir pour faire une jointure avec une table locale ou traiter puis insérer les données dans la base locale.

J'ai essayé via ce code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Private Sub createQuery() Dim oCnMySQL As ADODB.Connection Dim RSEntr As New ADODB.Recordset Dim rsdata As New ADODB.Recordset Dim RSSource As New ADODB.Recordset Dim ages As Variant Dim db As DAO.Database Dim datos As Double Set db = CurrentDb Dim qdf, qdf2, qdf3 As DAO.QueryDef 'DoCmd.DeleteObject acQuery, "rqcreate" Set qdf = db.CreateQueryDef("RQCreate", "select * from gepal") qdf.Connect = "ODBC;DSN=infolog C3" End Sub
Ensuite si je fais une requête appelant "rqcrreate", çà ne marche pas
Paut-être faut-il l'ajouter à la collection QueryDefs, j'ai essayé avec la méthode

Code:

db.Querydefs.append qdf

, mais çà ne marche pas.

Merci d'avance pour votre aide

Bonjour,

D'après ce que tu expliques, ce serait nettement plus simple de créer une table liée (synonyme table attachée) sur la table gepal.

Pour rester sur ta requête SQL directe en lisant ton code je crois que tu mélanges ADO et DAO.
A mon avis, il vaudrait mieux te limiter à la bibliothèque DAO... si tu travailles sur une application MDB.

A la création de la requête SQL directe, il faut aussi fixer sa propriété ReturnsRecords à True.
Dans ton cas, le Append n'est pas utile/nécessaire, car le CreateQueryDef est directement appelé sur le bon objet Database et la requête est automatiquement ajoutée à sa collection QueryDefs.
Mais son utilisation ne provoquera pas d'erreur (je crois).

Attention à une confusion classique en VB / VBA:
L'instruction Dim ne fonctionne pas comme en C ou en Pascal.
Si le type de données n'est pas précisé, alors il sera de type Variant.

Questions:
- Es-tu sûr que la chaîne de connexion est correcte ?
- As-tu essayé d'ouvrir une la requête rqcreate avec Access, en mode feuille de données ou même en mode création ?

Pour y voir plus clair, j'ai fait un peu de nettoyage dans ton code pour ne garder que l'essentiel.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Private Sub createQuery() Dim db As DAO.Database Dim qdf As DAO.QueryDef, qdf2 As DAO.QueryDef, qdf3 As DAO.QueryDef Set db = CurrentDb 'DoCmd.DeleteObject acQuery, "rqcreate" Set qdf = db.CreateQueryDef("RQCreate") With qdf .Connect = "ODBC;DSN=infolog C3" .SQL = "select * from gepal" .ReturnsRecords = True End With End Sub

C'est parfait mon cher =JBO=

çà marche très bien, en fait.
Pour répondre à ta question, j'utilise une requête SQL directe, car je vais exécuter une vraie instruction SQL, comme ici :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Case "DE" Set qdf = db.QueryDefs![RqDATLIV-DATEXP] qdf.Connect = "ODBC;dsn=" & RSEntr!dsn qdf.sql = "select refliv, datexp, datliv, livtot, cumlig from gehexpd " & _ " where datexp>" & datos & " and datexp<=" & maxdatdist Debug.Print qdf.sql Set qdf2 = db.CreateQueryDef("RQCreate") With qdf2 .Connect = "ODBC;DSN=infolog C2" .sql = "select refliv, datexp, datliv, livtot, cumlig from gehexpd " & _ " where datexp>" & datos & " and datexp<=" & maxdatdist & " and (gehexpd.REFLIV Like '%MACHIN%' or gehexpd.REFLIV Like '%BIDULE%')" .ReturnsRecords = True End With Debug.Print qdf2.sql str = "select sum(uvcecart)/max(totliv) as txservpcs, sum(ligecart)/max(ligliv) as txservlig, sum(cdecart)/max(cdeliv) as txservcde, datexp, 'C3' as entrepot, format(Datepart('ww',DateSerial(CInt(Left(Str(datexp),5)),CInt(Mid(Str(datexp),6,2)),CInt(Right(Str(datexp),2))),2),'00') AS semaine from( " & _ " SELECT count(refliv) AS cdecart, datexp, sum(livtot) AS uvcecart, datediff('d',DateSerial(CInt(Left(Str(datexp),5)),CInt(Mid(Str(datexp),6,2)),CInt(Right(Str(datexp),2))),DateSerial(CInt(Left(Str(datliv),5)),CInt(Mid(Str(datliv),6,2)),CInt(Right(Str(datliv),2)))) as jecart, " & _ " sum(cumlig) AS ligecart, (select count(refliv) from [RqDATLIV-DATEXP] as T1 where T1.datexp=T2.datexp group by datexp) AS cdeliv, " & _ " (select sum(cumlig) from [RqDATLIV-DATEXP] as T1 where T1.datexp=T2.datexp group by datexp) AS ligliv, " & _ " (select sum(livtot) from [RqDATLIV-DATEXP] as T1 where T1.datexp=T2.datexp group by datexp) AS totliv " & _ " FROM (SELECT * from [RqDATLIV-DATEXP] union SELECT * from RQCreate) as T2 " & _ " GROUP BY datexp, datediff('d',DateSerial(CInt(Left(Str(datexp),5)),CInt(Mid(Str(datexp),6,2)),CInt(Right(Str(datexp),2))),DateSerial(CInt(Left(Str(datliv),5)),CInt(Mid(Str(datliv),6,2)),CInt(Right(Str(datliv),2)))) " & _ " having datediff('d',DateSerial(CInt(Left(Str(datexp),5)),CInt(Mid(Str(datexp),6,2)),CInt(Right(Str(datexp),2))),DateSerial(CInt(Left(Str(datliv),5)),CInt(Mid(Str(datliv),6,2)),CInt(Right(Str(datliv),2))))<0) group by datexp"
Code dans lequel je paramètre une première requête ([RqDATLIV-DATEXP]) qui va me chercher des données dans une base externe (AS/400), puis je crée dynamiquement "Rqcreate", qui va me chercher des données dans une autre base. Je colle les deux par une requête union (en bleu), puis je fais des traitements en SQL sur cette union (en l'occurence ici, c'est des calculs de nombre de jours de retard), SQL étant de loin le plus performant pour faire des traitements.
Jusque là, j'étais obligé de créer des requêtes manuellement dans ma base, car je ne savais que les paramétrer (SQL, connect...), et ces requêtes s'amoncelaient. Avec cette solution de création dynamique, quand les requêtes sont utilisées, je les supprime, et çà me fait une base libérée de tous ces objets, ce qui n'est peut-être pas négligeable en terme de place, et de gestion.

Merci encore, ta contribution m'ouvre de belles possibilités.
Merci aussi à P. JOCHMANS pour sa participation.

25/06/2009, 14h09
=JBO=

Bonjour patbeautifulday,

Merci pour ton message qui montre tout l'intérêt de ta question initiale, à savoir:
utiliser Access pour intégrer des données provenant de bases de données hétérogènes mais en utilisant les ressources des SGBD externes pour filtrer les enregistrements, d'où l'utilisation de requêtes SQL directes.

Citation:

Envoyé par patbeautifulday

Jusque là, j'étais obligé de créer des requêtes manuellement dans ma base, car je ne savais que les paramétrer (SQL, connect...), et ces requêtes s'amoncelaient. Avec cette solution de création dynamique, quand les requêtes sont utilisées, je les supprime, et çà me fait une base libérée de tous ces objets, ce qui n'est peut-être pas négligeable en terme de place, et de gestion.

Cette solution de création dynamique a un coût en terme de conception et de programmation (notamment se frotter à VBA et DAO).
En revanche, le gain est immense en terme de nombre d'objets dans la base MDB (requêtes), et donc en maintenance et, surtout, ta solution est extensible de par sa conception.

Donc c'est du bon boulot ! :ccool:

Une petite remarque sur l'aspect totalement dynamique:

Puisque tu utilises toujours les 2 mêmes requêtes SQL directes, il n'est pas nécessaire de les recréer à chaque changement de paramètres.
Il est plus simple de seulement modifier leur propriété .SQL.
Ainsi, Access (en fait JET) n'a pas besoin de gérer la suppression / création de ces objets, ce sera encore plus rapide (et ça évitera de faire grossir les tables systèmes du fichier MDB ou encore, si tu gères la sécurité, de réaffecter les droits des utilisateurs côté Access, mais aussi de re-paramétrer la chaîne de connexion côté ODBC pour UID et PWD).

Une solution totalement dynamique serait justifiée si tu voulais pouvoir donner un nom différent aux requêtes SQL directes pour les conserver et pouvoir toutes les gérer en parallèle.
Par exemple pour afficher simultanément plusieurs feuilles de données qui font chacune l'UNION de données issues ses bases AS/400 et Infolog, mais pour des paramètres différents.
Et là encore, si tu ne veux pas re-paramétrer dynamiquement la chaîne de connexion, tu peux imaginer une requête SQL directe "modèle" dont la propriété .Connect serait recopiée pour chaque nouvelle requête SQL directe.

Ainsi, la chaîne de connexion ne serait jamais construite par le code VBA, donc pas de nom d'utilisateur ni de mot de passe "en dur".
_