creation de requete à partir d'une table

max-75 <maxlamenace75@gmail.com> écrivait news:9d80d665-3110-405c-adfb-
6105ab5ddb1d@l14g2000pro.googlegroups.com:

‚tant de migrer un reporting d'une 40taine de requetes qui se
fait actuellement via des requetes ODBC … partir d'Excel 2007..

Heu...

Es tu au courant qu'access peut aussi s'utiliser sans connaissance de
programmation particulièrement poussée ?

Dans ton cas, il te suffira de cliquer sur la barre de tache, "fichier /
données externes / lier les tables", puis type de fihier = excel, et le
chemin d'accès.. et voilà!

Bonjour,

max-75 a écrit, le 02/05/2011 16:51 :

L'idée étant de migrer un reporting d'une 40taine de requetes qui s e
fait actuellement via des requetes ODBC à partir d'Excel 2007..

Je soupçonne que l'idée-clef, qui te retient d'exploiter l'idée de
Morpheeus, est là. Si c'était une requête ça irait très bien pa r une
liaison, mais une quarantaine ...

Seulement, quelques éléments supplémentaires aideraient bien pour d onner
une idée de par où on pourrait bien commencer ...

Cela étant, si il y a quarante tables à gérer, il est à noter qu' on peut
commencer par créer quarante tables liées. Puis créer les différe nts
états basés dessus.

Après, quand il ne reste plus qu'à les enchaîner, ça devient larg ement
plus simple.

On 4 mai, 23:09, Gloops <glo...@invalid.zailes.org> wrote:

Bonjour,

max-75 a écrit, le 02/05/2011 16:51 :

> L'idée étant de migrer un reporting d'une 40taine de requetes qui s e
> fait actuellement via des requetes ODBC à partir d'Excel 2007..

Je soupçonne que l'idée-clef, qui te retient d'exploiter l'idée de
Morpheeus, est là. Si c'était une requête ça irait très bien pa r une
liaison, mais une quarantaine ...

Seulement, quelques éléments supplémentaires aideraient bien pour d onner
une idée de par où on pourrait bien commencer ...

Cela étant, si il y a quarante tables à gérer, il est à noter qu' on peut
commencer par créer quarante tables liées. Puis créer les différe nts
états basés dessus.

Après, quand il ne reste plus qu'à les enchaîner, ça devient larg ement
plus simple.

Bonjour,

Merci pour votre interet à mon probleme.
Pour repondre à Morpheus, je connais tres bien cette fonctionalite de
tables liées.
Pour 'simplifier mon probleme, je vais essayer de le reformuler (celà
sera un premier pas pour le regler pas vrai?):
Donc, je possede un fichier excel avec env 40-50 code sql (select)
dont j'aimerais rappatrier le resultat dans des tables locale. celà me
permettra de recreer la structure de mon dashboard.
Chaque code attaque des tables distantes potentiellement differentes
et peut rapatrier des productions de carottes ou l'evolution de la
meteo du mois dernier.
Ce que je souhaite eviter, c'est de répéter 40-50 fois cette sequence:

1/ copier le code sql contenu dans excel
2/ le coller pour creer une requete direct sur la base de donnée
oracle
3/ lui donner un nom
4/ creer une requete de creation de table pour la requete directe
5/ creer une requete update (pour actualiser les tables rappatriées
localement lors à chaque actualisation de mon dashboard)

Je me disais qu'en liant mon fichier excel (telque morpheus
l'explique) et en lui donnant en colonne toutes les variables
necessaires, une boucle vba pourrait automatiser ce process.

ce qui me bloque avant tout, c'est de recuperer dans des variables le
contenu chaque ligne du recordset (ma table excel liée)

Apres, il me restera à ramer avec les querydefs. pour passer le code,
le nom de la query direct, ex...

NB: Je souhaite rappatrier les donnees en locale pour 2 raisons:

a/ Bien que mes rapports produisent des tableaux de bords, il est
frequent que l'on me demande les données sous forme de liste (dans ce
cas, je prefere les archiver localement)
b/ Je dois souvent faire quelques mapping de données qui ne sont pas
dans notre base oracle (ex: pierre et paul dans le groupe des bleus,
jacques dans le groupe des rouges)


NB2: Comme vous vous en doutez, je suis vraiment debutant en vba
Access et j'utilise une version anglaise ce qui explique que mes
termes soient approximatifs.

max-75 a écrit, le 06/05/2011 14:32 :

Bonjour,

Merci pour votre interet à mon probleme.
Pour repondre à Morpheus, je connais tres bien cette fonctionalite de
tables liées.
Pour 'simplifier mon probleme, je vais essayer de le reformuler (celà
sera un premier pas pour le regler pas vrai?):

Absolument.
Après une bonne marche je rentre insuffisamment frais pour évaluer
jusqu'à quel point, mais dans le principe la démarche est la bonne.

Donc, je possede un fichier excel avec env 40-50 code sql (select)
dont j'aimerais rappatrier le resultat dans des tables locale. celà m e
permettra de recreer la structure de mon dashboard.

Peut-être est-ce la brume qui m'empêche de situer, mais j'en appelle à
une précision. Donc, en fait, c'est le code SQL, donc tu le colles dans
un fichier Excel, mais si tu l'avais stocké dans un fichier texte ça
n'aurait pas posé de problème, si ce n'est la présentation ?

Par contraste avec le résultat de la requête, constitué de colonnes , qui
lui au contraire gagne à être présenté dans un tableur.

Chaque code attaque des tables distantes potentiellement differentes
et peut rapatrier des productions de carottes ou l'evolution de la
meteo du mois dernier.
Ce que je souhaite eviter, c'est de répéter 40-50 fois cette sequen ce:

1/ copier le code sql contenu dans excel
2/ le coller pour creer une requete direct sur la base de donnée
oracle
3/ lui donner un nom
4/ creer une requete de creation de table pour la requete directe
5/ creer une requete update (pour actualiser les tables rappatriées
localement lors à chaque actualisation de mon dashboard)

Je me disais qu'en liant mon fichier excel (telque morpheus
l'explique) et en lui donnant en colonne toutes les variables
necessaires, une boucle vba pourrait automatiser ce process.

ce qui me bloque avant tout, c'est de recuperer dans des variables le
contenu chaque ligne du recordset (ma table excel liée)

Apres, il me restera à ramer avec les querydefs. pour passer le code,
le nom de la query direct, ex...

NB: Je souhaite rappatrier les donnees en locale pour 2 raisons:

a/ Bien que mes rapports produisent des tableaux de bords, il est
frequent que l'on me demande les données sous forme de liste (dans ce
cas, je prefere les archiver localement)
b/ Je dois souvent faire quelques mapping de données qui ne sont pas
dans notre base oracle (ex: pierre et paul dans le groupe des bleus,
jacques dans le groupe des rouges)


NB2: Comme vous vous en doutez, je suis vraiment debutant en vba
Access et j'utilise une version anglaise ce qui explique que mes
termes soient approximatifs.

Malgré mon esprit embrumé, je crois que j'arrive à entrer dans le s ujet
au moins un peu. Le principal développement de ma dernière mission a
consisté en une interface sous Access, qui présente un formulaire
servant d'interface pour saisir des paramètres (numéros de dossiers,
numéros de factures, ...) à placer dans des requêtes, et une fois q ue
c'est fait, j'extrais le résultat de la requête sous forme de fichier
Excel, pour l'envoyer par messagerie.

S'agit-il bien d'un sujet proche ?

Une première gymnastique à pratiquer consiste à basculer l'éditeu r de
requête en mode SQL, pour copier le code SQL, le coller dans Word,
vérifier que les ruptures de lignes sont placées aux bons endroits, p uis
lancer dans Word une commande de remplacement
de ^p
par "^p strSQL = strSQL + "

Une fois que c'est fait, il y a un strSQL = strSQL + à récupérer en fin
de requête pour le replacer au début, et là en fait strSQL = et o n passe
directement aux guillemets, puisqu'on n'est pas supposé avoir quelque
chose dans la variable au début du traitement.

A la suite, ajouter ce qu'il faut d'instruction pour évaluer le résul tat

Debug.Print strSQL
MsgBox strSQL

Ne pas oublier, aux endroits judicieux après le WHERE, de remplacer le
champ concerné par le contrôle de saisie où l'utilisateur fournit l a
valeur qui l'intéresse.

Une fois qu'on est satisfait du résultat l'instruction DoCmd.RunSQL
permet de lancer l'exécution.
Oops, ma langue a fourché, ce que je viens de dire est valable pour une
requête exécution (DELETE, INSERT), mais si il y a des données à
retourner (SELECT) il faut ouvrir un jeu d'enregistrements.

Bon là, j'attends le retour, pour m'assurer que je ne suis pas en train
de me fourvoyer sur une fausse piste, auquel cas j'aurai déjà été
vachement long.

On 6 mai, 17:44, Gloops <glo...@invalid.zailes.org> wrote:

max-75 a écrit, le 06/05/2011 14:32 :

> Bonjour,

> Merci pour votre interet à mon probleme.
> Pour repondre à Morpheus, je connais tres bien cette fonctionalite de
> tables liées.
> Pour 'simplifier mon probleme, je vais essayer de le reformuler (celà
> sera un premier pas pour le regler pas vrai?):

Absolument.
Après une bonne marche je rentre insuffisamment frais pour évaluer
jusqu'à quel point, mais dans le principe la démarche est la bonne.

> Donc, je possede un fichier excel avec env 40-50 code sql (select)
> dont j'aimerais rappatrier le resultat dans des tables locale. celà m e
> permettra de recreer la structure de mon dashboard.

Peut-être est-ce la brume qui m'empêche de situer, mais j'en appelle à
une précision. Donc, en fait, c'est le code SQL, donc tu le colles dans
un fichier Excel, mais si tu l'avais stocké dans un fichier texte ça
n'aurait pas posé de problème, si ce n'est la présentation ?

Par contraste avec le résultat de la requête, constitué de colonnes , qui
lui au contraire gagne à être présenté dans un tableur.





> Chaque code attaque des tables distantes potentiellement differentes
> et peut rapatrier des productions de carottes ou l'evolution de la
> meteo du mois dernier.
> Ce que je souhaite eviter, c'est de répéter 40-50 fois cette sequen ce:

> 1/ copier le code sql contenu dans excel
> 2/ le coller pour creer une requete direct sur la base de donnée
> oracle
> 3/ lui donner un nom
> 4/ creer une requete de creation de table pour la requete directe
> 5/ creer une requete update (pour actualiser les tables rappatriées
> localement lors à chaque actualisation de mon dashboard)

> Je me disais qu'en liant mon fichier excel (telque morpheus
> l'explique) et en lui donnant en colonne toutes les variables
> necessaires, une boucle vba pourrait automatiser ce process.

> ce qui me bloque avant tout, c'est de recuperer dans des variables le
> contenu chaque ligne du recordset (ma table excel liée)

> Apres, il me restera à ramer avec les querydefs. pour passer le code,
> le nom de la query direct, ex...

> NB: Je souhaite rappatrier les donnees en locale pour 2 raisons:

> a/ Bien que mes rapports produisent des tableaux de bords, il est
> frequent que l'on me demande les données sous forme de liste (dans ce
> cas, je prefere les archiver localement)
> b/ Je dois souvent faire quelques mapping de données qui ne sont pas
> dans notre base oracle (ex: pierre et paul dans le groupe des bleus,
> jacques dans le groupe des rouges)

> NB2: Comme vous vous en doutez, je suis vraiment debutant en vba
> Access et j'utilise une version anglaise ce qui explique que mes
> termes soient approximatifs.

Malgré mon esprit embrumé, je crois que j'arrive à entrer dans le s ujet
au moins un peu. Le principal développement de ma dernière mission a
consisté en une interface sous Access, qui présente un formulaire
servant d'interface pour saisir des paramètres (numéros de dossiers,
numéros de factures, ...) à placer dans des requêtes, et une fois q ue
c'est fait, j'extrais le résultat de la requête sous forme de fichier
Excel, pour l'envoyer par messagerie.

S'agit-il bien d'un sujet proche ?

Une première gymnastique à pratiquer consiste à basculer l'éditeu r de
requête en mode SQL, pour copier le code SQL, le coller dans Word,
vérifier que les ruptures de lignes sont placées aux bons endroits, p uis
lancer dans Word une commande de remplacement
de ^p
par "^p    strSQL = strSQL + "

Une fois que c'est fait, il y a un strSQL = strSQL + à récupérer en fin
de requête pour le replacer au début, et là en fait strSQL = et o n passe
directement aux guillemets, puisqu'on n'est pas supposé avoir quelque
chose dans la variable au début du traitement.

A la suite, ajouter ce qu'il faut d'instruction pour évaluer le résul tat

Debug.Print strSQL
MsgBox strSQL

Ne pas oublier, aux endroits judicieux après le WHERE, de remplacer le
champ concerné par le contrôle de saisie où l'utilisateur fournit l a
valeur qui l'intéresse.

Une fois qu'on est satisfait du résultat l'instruction DoCmd.RunSQL
permet de lancer l'exécution.
Oops, ma langue a fourché, ce que je viens de dire est valable pour une
requête exécution (DELETE, INSERT), mais si il y a des données à
retourner (SELECT) il faut ouvrir un jeu d'enregistrements.

Bon là, j'attends le retour, pour m'assurer que je ne suis pas en train
de me fourvoyer sur une fausse piste, auquel cas j'aurai déjà été
vachement long.- Masquer le texte des messages précédents -

- Afficher le texte des messages précédents -

:-)
il parait que dans les années 60, chanter les chansons anglaises "en
yaourt" etait à la mode.
Si certains ne connaissent pas, Celà consistait à chanter l'air avec
des mots en francais approchants phonetiquement.
voici ce que celà donnerait ici j'imagine:

For each row of MyTable " "( 'mon fichier lié)

MyConnection= (ma chaine de connexion)
NameOfQuery= QRYNAME (un champs de "MyTable". la valeur corresponds à
la ligne active)
MySQLCode=MYCODE (un champs de "MyTable". la valeur corresponds à la
ligne active)
LocalTableName=LocalName (un champs de "MyTable". la valeur
corresponds à la ligne active)
UpdateMyTable=UpdateName (un champs de "MyTable". la valeur
corresponds à la ligne active)

passthoughquery.create
.name = NameOfQuery
.sqlCode = MySQLCode
maketablequery.create
.Name="mkt"&NameOfQuery
.sqlcode='select * from NameOfQuery
into' & LocalTableName
UpdateTable.create
.name="Up"& LocalTableName

Voici un peu l'air que celà aurait...(chansonnier est un autre
metier....)

Pour revenir à la genese, j'utilisais un fichier excel 2007 pour
lancer quelques requetes sur une base oracle (1 onglet par requete).
Dans un 2e fichier, je manipulais mes données (tcd etc..)
Dans un 3e la mise en forme qui etait envoyée.
Mais comme vous devais le savoir, en general, on vous demande un
doigt, vous proposez une main et au final on vous exige un bras...
(heureusement qu'il m'en reste un pour demander de l'aide).
Jai donc ecris un script pour rassembler tous les codes sql de mes
fichiers xlsx sous forme de table et je souhaite recreer mes
extraction sous access...

J'espere que celà eclaire le smilblick....

max-75 a écrit, le 06/05/2011 18:29 :

J'espere que celà eclaire le smilblick....

Ben ... pas trop.
J'avais cru que je commençais à comprendre un peu, et puis voilà qu e
maintenant on nage dans le yaourt ...

Bon je pense avoir trouve ce que je cherchais. J'ai un peu tout
simplifier pour arriver à mes fins.
Evidemment, on sent bien que c'est du bidouillage mais ca a fonctionné
donc c'est parfait....je suis sur que maintenant, vous allez trouver
que mon probleme etait simple...
En resumé, j'avais une table structure contenant 2 champs: sqlcode et
localtable.
Le but est, pour chaque ligne de rapatrier les datas (base oracle)
dans la localTable
Pour celà, creer une boucle pour chaque valeur de sqlCode, creer la
query directe, creer la query maketable pour rappatier le resultat
dans un table locale (valeur de LocalTable).
J'imagine les puristes s'arracher les cheveux mais comme j'ai dis, mes
connaissances en VBA sont tres limitees. Il n' a donc aucune
nomenclature de respectée (sauf pur hasard independant de ma
volonté :).
Evidemment, le code peut certainement etre optimisé si d'autres
souhaitent le reutilisé.

Option Compare Database
Sub CreateStructure()
Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim qdf As QueryDef
Dim StrSql As String
Dim localtable As String
Dim DirectqueryName As String
Dim mkquery As String


Set dbs = CurrentDb
Set rst = dbs.OpenRecordset("SELECT * FROM structure order by ID") '
table qui structure mon reporting
If rst.EOF = False And rst.BOF = False Then
rst.MoveFirst
Do While rst.EOF = False
'
' Code execute pour chaque ligne de ma structure
'

StrSql = rst!sqlcode 'recuper le code de la ligne en cours de la table
structure
localtable = rst!localtable 'recupere le nom à donne à ma table local e
DirectqueryName = "Dqry" & localtable 'crée le nom de la query directe
mkquery = "MK" & localtable 'crée la query de création de table

Set qdf = dbs.CreateQueryDef(DirectqueryName) 'crée la query directe

qdf.Connect = ma chaine de connexion 'chaine de connection pour la
base distante à copier en dur ici

qdf.SQL = StrSql 'variable ou est stockée le code de query directe à
execute

StrSql = "select * into " & localtable & " from " & DirectqueryName
'Sql pour créer la table locale
Set qdf = dbs.CreateQueryDef(mkquery, StrSql)

DoCmd.RunSQL StrSql 'launch of maketable



'
'fin Code execute pour chaque ligne de ma structure
'
'
rst.MoveNext
Loop
End If
rst.Close
Set rst = Nothing
dbs.Close
Set dbs = Nothing
End Sub

max-75 a écrit, le 09/05/2011 17:29 :

J'imagine les puristes s'arracher les cheveux mais comme j'ai dis, mes
connaissances en VBA sont tres limitees. Il n' a donc aucune
nomenclature de respectée (sauf pur hasard independant de ma
volonté :).

Argh, j'ai déjà eu à passer derrière quelqu'un qui s'était dé battu comme
ça sur l'application quelques années. Ce n'est pas l'aspect le plus
plaisant de la profession.

Cela étant, la personne s'est quand même montrée capable de bien
m'expliquer, en deux jours, de quoi elle avait besoin, ce qui m'a permis
de monter une structure qui s'est avérée tenir la route.
Au final il y a eu des trucs sympa à faire là-dessus.