J'ai =E0 faire vers Access un import depuis un fichier Excel, dont je doi=
s=20
dire qu'il n'est pas trop mochement structur=E9, puisqu'=E0 une ent=EAte =
de=20
colonne pr=E8s toutes les cellules sont rep=E9r=E9es par un titre de colo=
nne=20
et un titre de ligne, ce qui fait qu'on peut utiliser des DGet pour=20
extraire une valeur d'une colonne en connaissant la valeur d'une ou deux =
autres.
L'ennui avec DGet, c'est qu'il faut lui fournir un champ de crit=E8res,=20
qui comporte les noms de champs sur la premi=E8re ligne et la ou les=20
valeurs accept=E9es sur les suivantes.
Si on a =E0 traiter en boucle tout le tableau, =E7a serait quand m=EAme=20
largement plus pratique de pouvoir fournir les arguments en ligne dans=20
la commande, comme on fait sous SQL.
Si j'importe le tableau dans une table temporaire sous Access je pourrai =
faire =E7a facilement, mais je cherche =E0 optimiser tant en temps de=20
traitement qu'en lisibilit=E9 pour celui qui aura =E0 faire de la mainten=
ance.
Alors, une requ=EAte SQL sur un champ Excel, depuis Access, possible, ou =
pas ?
Un certain Croquignol a pos=E9 une question tr=E8s proche il y a un peu p=
lus=20
de deux ans (sans parler d'Access au demeurant) sur excel-downloads.com, =
sans grand succ=E8s, mais qui sait j'aurai peut-=EAtre plus de chance ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gloops
Bon, si quelqu'un trouve, ça peut être bon à noter, mais vous embê tez pas, j'ai importé la feuille dans une table par un DoCmd.ImportSpreadSheet (pas sûr de la casse ...), et après on tritur e ça dans tous les sens qu'on veut avec des requêtes SQL ou des DGet, p our transférer ça dans les tables qui vont bien.
Je vous fais grâce de ce qui m'a été proposé par mon prédéces seur. _____________________________________ Gloops a écrit, le 03/10/2010 15:57 :
Bonjour tout le monde,
J'ai à faire vers Access un import depuis un fichier Excel, dont je d ois dire qu'il n'est pas trop mochement structuré, puisqu'à une entêt e de colonne près toutes les cellules sont repérées par un titre de co lonne et un titre de ligne, ce qui fait qu'on peut utiliser des DGet pour extraire une valeur d'une colonne en connaissant la valeur d'une ou deu x autres.
L'ennui avec DGet, c'est qu'il faut lui fournir un champ de critères, qui comporte les noms de champs sur la première ligne et la ou les valeurs acceptées sur les suivantes.
Si on a à traiter en boucle tout le tableau, ça serait quand même largement plus pratique de pouvoir fournir les arguments en ligne dans la commande, comme on fait sous SQL.
Si j'importe le tableau dans une table temporaire sous Access je pourra i faire ça facilement, mais je cherche à optimiser tant en temps de traitement qu'en lisibilité pour celui qui aura à faire de la maint enance.
Alors, une requête SQL sur un champ Excel, depuis Access, possible, o u pas ?
Un certain Croquignol a posé une question très proche il y a un peu plus de deux ans (sans parler d'Access au demeurant) sur excel-downloads.com , sans grand succès, mais qui sait j'aurai peut-être plus de chance ?
Bon, si quelqu'un trouve, ça peut être bon à noter, mais vous embê tez
pas, j'ai importé la feuille dans une table par un
DoCmd.ImportSpreadSheet (pas sûr de la casse ...), et après on tritur e
ça dans tous les sens qu'on veut avec des requêtes SQL ou des DGet, p our
transférer ça dans les tables qui vont bien.
Je vous fais grâce de ce qui m'a été proposé par mon prédéces seur.
_____________________________________
Gloops a écrit, le 03/10/2010 15:57 :
Bonjour tout le monde,
J'ai à faire vers Access un import depuis un fichier Excel, dont je d ois
dire qu'il n'est pas trop mochement structuré, puisqu'à une entêt e de
colonne près toutes les cellules sont repérées par un titre de co lonne
et un titre de ligne, ce qui fait qu'on peut utiliser des DGet pour
extraire une valeur d'une colonne en connaissant la valeur d'une ou deu x
autres.
L'ennui avec DGet, c'est qu'il faut lui fournir un champ de critères,
qui comporte les noms de champs sur la première ligne et la ou les
valeurs acceptées sur les suivantes.
Si on a à traiter en boucle tout le tableau, ça serait quand même
largement plus pratique de pouvoir fournir les arguments en ligne dans
la commande, comme on fait sous SQL.
Si j'importe le tableau dans une table temporaire sous Access je pourra i
faire ça facilement, mais je cherche à optimiser tant en temps de
traitement qu'en lisibilité pour celui qui aura à faire de la maint enance.
Alors, une requête SQL sur un champ Excel, depuis Access, possible, o u
pas ?
Un certain Croquignol a posé une question très proche il y a un peu plus
de deux ans (sans parler d'Access au demeurant) sur excel-downloads.com ,
sans grand succès, mais qui sait j'aurai peut-être plus de chance ?
Bon, si quelqu'un trouve, ça peut être bon à noter, mais vous embê tez pas, j'ai importé la feuille dans une table par un DoCmd.ImportSpreadSheet (pas sûr de la casse ...), et après on tritur e ça dans tous les sens qu'on veut avec des requêtes SQL ou des DGet, p our transférer ça dans les tables qui vont bien.
Je vous fais grâce de ce qui m'a été proposé par mon prédéces seur. _____________________________________ Gloops a écrit, le 03/10/2010 15:57 :
Bonjour tout le monde,
J'ai à faire vers Access un import depuis un fichier Excel, dont je d ois dire qu'il n'est pas trop mochement structuré, puisqu'à une entêt e de colonne près toutes les cellules sont repérées par un titre de co lonne et un titre de ligne, ce qui fait qu'on peut utiliser des DGet pour extraire une valeur d'une colonne en connaissant la valeur d'une ou deu x autres.
L'ennui avec DGet, c'est qu'il faut lui fournir un champ de critères, qui comporte les noms de champs sur la première ligne et la ou les valeurs acceptées sur les suivantes.
Si on a à traiter en boucle tout le tableau, ça serait quand même largement plus pratique de pouvoir fournir les arguments en ligne dans la commande, comme on fait sous SQL.
Si j'importe le tableau dans une table temporaire sous Access je pourra i faire ça facilement, mais je cherche à optimiser tant en temps de traitement qu'en lisibilité pour celui qui aura à faire de la maint enance.
Alors, une requête SQL sur un champ Excel, depuis Access, possible, o u pas ?
Un certain Croquignol a posé une question très proche il y a un peu plus de deux ans (sans parler d'Access au demeurant) sur excel-downloads.com , sans grand succès, mais qui sait j'aurai peut-être plus de chance ?
3stone
Salut,
Gloops wrote:
Bon, si quelqu'un trouve, ça peut être bon à noter, mais vous embêtez pas, j'ai importé la feuille dans une table par un DoCmd.ImportSpreadSheet (pas sûr de la casse ...), et après on triture ça dans tous les sens qu'on veut avec des requêtes SQL ou des DGet, pour transférer ça dans les tables qui vont bien.
Bon, si quelqu'un trouve, ça peut être bon à noter, mais vous embêtez
pas, j'ai importé la feuille dans une table par un
DoCmd.ImportSpreadSheet (pas sûr de la casse ...), et après on triture
ça dans tous les sens qu'on veut avec des requêtes SQL ou des DGet,
pour transférer ça dans les tables qui vont bien.
Bon, si quelqu'un trouve, ça peut être bon à noter, mais vous embêtez pas, j'ai importé la feuille dans une table par un DoCmd.ImportSpreadSheet (pas sûr de la casse ...), et après on triture ça dans tous les sens qu'on veut avec des requêtes SQL ou des DGet, pour transférer ça dans les tables qui vont bien.
Bon, si quelqu'un trouve, ça peut être bon à noter, mais vous em bêtez pas, j'ai importé la feuille dans une table par un DoCmd.ImportSpreadSheet (pas sûr de la casse ...), et après on tri ture ça dans tous les sens qu'on veut avec des requêtes SQL ou des DGet , pour transférer ça dans les tables qui vont bien.
Ah bon, tu fais des DGet sous Access, toi ?
Hum, à y regarder de plus près, c'était plutôt des Dlookup.
Ou alors sinon DGet c'est en méthode de WorksheetFunction (appel à Ex cel donc), du coup là on n'a rien résolu.
Après toutes ces versions d'Excel qui mettaient Dlookup dans la feuille de données (maintenant j'ai BDLire) et DGet dans le module, pour la mê me chose ... après le trajet j'ai confondu.
3stone a écrit, le 04/10/2010 23:16 :
Salut,
Gloops wrote:
Bon, si quelqu'un trouve, ça peut être bon à noter, mais vous em bêtez
pas, j'ai importé la feuille dans une table par un
DoCmd.ImportSpreadSheet (pas sûr de la casse ...), et après on tri ture
ça dans tous les sens qu'on veut avec des requêtes SQL ou des DGet ,
pour transférer ça dans les tables qui vont bien.
Ah bon, tu fais des DGet sous Access, toi ?
Hum, à y regarder de plus près, c'était plutôt des Dlookup.
Ou alors sinon DGet c'est en méthode de WorksheetFunction (appel à Ex cel
donc), du coup là on n'a rien résolu.
Après toutes ces versions d'Excel qui mettaient Dlookup dans la feuille
de données (maintenant j'ai BDLire) et DGet dans le module, pour la mê me
chose ... après le trajet j'ai confondu.
Bon, si quelqu'un trouve, ça peut être bon à noter, mais vous em bêtez pas, j'ai importé la feuille dans une table par un DoCmd.ImportSpreadSheet (pas sûr de la casse ...), et après on tri ture ça dans tous les sens qu'on veut avec des requêtes SQL ou des DGet , pour transférer ça dans les tables qui vont bien.
Ah bon, tu fais des DGet sous Access, toi ?
Hum, à y regarder de plus près, c'était plutôt des Dlookup.
Ou alors sinon DGet c'est en méthode de WorksheetFunction (appel à Ex cel donc), du coup là on n'a rien résolu.
Après toutes ces versions d'Excel qui mettaient Dlookup dans la feuille de données (maintenant j'ai BDLire) et DGet dans le module, pour la mê me chose ... après le trajet j'ai confondu.
