Il me semble que CurrentProject.Path renvoie une chaîne de caractèr es ne se terminant pas par un "".
Argh, il doit y avoir des astres qui passent trop près :)
J'ai mal lu, et j'ai insisté. :/
Donc, tu dis, Path est préfixé par CurrentProject et ne se termine pa s par une barre inverse.
Par ailleurs Jacques a démarré ses lignes d'exemple par "Excl.", ce q ui m'a fait supposer que Excl était un objet Excel ouvert au préalable, par Automation.
et ça signifie que le répertoire où se trouve le projet actuel, où on écrit le code ci-dessus, contient un sous-répertoire "Dossier Excel", où on va sauvegarder sous le nom "3ème Envoi.xls" le fichier ouvert dans l'objet Excl.
ça tombe bien que la base ne se trouve pas sous la racine du disque, sinon il y aurait eu lieu de vérifier que dans ce cas non plus on n'a pas de barre inverse à la fin de path.
Willi2004 a écrit, le 12/08/2007 13:01 :
Il me semble que CurrentProject.Path renvoie une chaîne de caractèr es ne se
terminant pas par un "".
Argh, il doit y avoir des astres qui passent trop près :)
J'ai mal lu, et j'ai insisté. :/
Donc, tu dis, Path est préfixé par CurrentProject et ne se termine pa s
par une barre inverse.
Par ailleurs Jacques a démarré ses lignes d'exemple par "Excl.", ce q ui
m'a fait supposer que Excl était un objet Excel ouvert au préalable, par
Automation.
et ça signifie que le répertoire où se trouve le projet actuel, où on
écrit le code ci-dessus, contient un sous-répertoire "Dossier Excel", où
on va sauvegarder sous le nom "3ème Envoi.xls" le fichier ouvert dans
l'objet Excl.
ça tombe bien que la base ne se trouve pas sous la racine du disque,
sinon il y aurait eu lieu de vérifier que dans ce cas non plus on n'a
pas de barre inverse à la fin de path.
Il me semble que CurrentProject.Path renvoie une chaîne de caractèr es ne se terminant pas par un "".
Argh, il doit y avoir des astres qui passent trop près :)
J'ai mal lu, et j'ai insisté. :/
Donc, tu dis, Path est préfixé par CurrentProject et ne se termine pa s par une barre inverse.
Par ailleurs Jacques a démarré ses lignes d'exemple par "Excl.", ce q ui m'a fait supposer que Excl était un objet Excel ouvert au préalable, par Automation.
et ça signifie que le répertoire où se trouve le projet actuel, où on écrit le code ci-dessus, contient un sous-répertoire "Dossier Excel", où on va sauvegarder sous le nom "3ème Envoi.xls" le fichier ouvert dans l'objet Excl.
ça tombe bien que la base ne se trouve pas sous la racine du disque, sinon il y aurait eu lieu de vérifier que dans ce cas non plus on n'a pas de barre inverse à la fin de path.
Pierre CFI [mvp]
salut oui, il ne faut pas d'espace Excl.SaveAs path & "Dossier Excel3ème Envoi.xls"
si path est vide, là pb, car ou se trouve la base ?? :o))
-- Pierre MVP Access *************************************** Conseils MPFA: http://www.mpfa.info/ ********************************************************* "Gloops" a écrit dans le message de news: OCQ7% Pierre CFI [mvp] a écrit, le 11/08/2007 11:01 :
Il y a des chances que ça marche mieux en enlevant l'espace devant Dossier, et en s'assurant que path ne se termine pas par un "", auquel cas il y aurait lieu de ne pas en ajouter un autre.
La coupure de ligne ne sera peut-être pas indispensable une fois sorti du newsgroup.
Attention, je n'ai pas épuisé le sujet : il reste le cas où path est vide, et il convient encore de distinguer celui où path contient le chemin vers la racine d'un disque (a priori, Len(path) = 3 si on a "C:"), et encore le cas du chemin UNC (serveurdomaine)
Ensuite dans certains contextes il y a lieu de doubler systématiquement les barres inverses, mais il ne me semble pas que le SaveAs soit concerné.
Ou alors, vous avez tous plaisanté et je suis tombé dans le panneau ?
salut
oui, il ne faut pas d'espace
Excl.SaveAs path & "Dossier Excel3ème Envoi.xls"
si path est vide, là pb, car ou se trouve la base ?? :o))
--
Pierre
MVP Access
***************************************
Conseils MPFA: http://www.mpfa.info/
*********************************************************
"Gloops" <gloops@niark.invalid> a écrit dans le message de news:
OCQ7%237M3HHA.5360@TK2MSFTNGP03.phx.gbl...
Pierre CFI [mvp] a écrit, le 11/08/2007 11:01 :
Il y a des chances que ça marche mieux en enlevant l'espace devant
Dossier, et en s'assurant que path ne se termine pas par un "", auquel
cas il y aurait lieu de ne pas en ajouter un autre.
La coupure de ligne ne sera peut-être pas indispensable une fois sorti
du newsgroup.
Attention, je n'ai pas épuisé le sujet : il reste le cas où path est
vide, et il convient encore de distinguer celui où path contient le
chemin vers la racine d'un disque (a priori, Len(path) = 3 si on a
"C:"), et encore le cas du chemin UNC (\serveurdomaine)
Ensuite dans certains contextes il y a lieu de doubler systématiquement
les barres inverses, mais il ne me semble pas que le SaveAs soit concerné.
Ou alors, vous avez tous plaisanté et je suis tombé dans le panneau ?
salut oui, il ne faut pas d'espace Excl.SaveAs path & "Dossier Excel3ème Envoi.xls"
si path est vide, là pb, car ou se trouve la base ?? :o))
-- Pierre MVP Access *************************************** Conseils MPFA: http://www.mpfa.info/ ********************************************************* "Gloops" a écrit dans le message de news: OCQ7% Pierre CFI [mvp] a écrit, le 11/08/2007 11:01 :
Il y a des chances que ça marche mieux en enlevant l'espace devant Dossier, et en s'assurant que path ne se termine pas par un "", auquel cas il y aurait lieu de ne pas en ajouter un autre.
La coupure de ligne ne sera peut-être pas indispensable une fois sorti du newsgroup.
Attention, je n'ai pas épuisé le sujet : il reste le cas où path est vide, et il convient encore de distinguer celui où path contient le chemin vers la racine d'un disque (a priori, Len(path) = 3 si on a "C:"), et encore le cas du chemin UNC (serveurdomaine)
Ensuite dans certains contextes il y a lieu de doubler systématiquement les barres inverses, mais il ne me semble pas que le SaveAs soit concerné.
Ou alors, vous avez tous plaisanté et je suis tombé dans le panneau ?
Willi2004
c'est si on n'avait pas eu de barre inverse à la fin de path qu'on aurait écrit
Excl.SaveAs path + "Dossier Excel3ème Envoi.xls"
ceci signifie que le répertoire où se trouve la base Access contient un sous-répertoire DossierExcel, dans lequel on sauvegarde un fichier 3èmeEnvoi.xls
__________________________________ Oui, c'est exactement ce que j'ai pensé.
"Gloops" a écrit dans le message de news: % Willi2004 a écrit, le 12/08/2007 13:01 :
Bonjour Gloops. Le guillemet de la fin, c'est pour fermer le guillemet devant path. On pourrait aussi écrire: Excl.SaveAs "path" & "Dossier Excel3ème Envoi.xls"
Ou encore: Excl.SaveAs "path" & "" & "Dossier Excel3ème Envoi.xls"
Oui, d'accord, mais si on a un répertoire qui s'appelle "path", utilisé en chemin relatif sur le chemin par défaut, à quoi bon une concaténation ?
Il suffirait alors de dire "pathDossier Excel3ème Envoi.xls" et là, si ça ne marche pas, c'est que le chemin par défaut n'a pas bien été sélectionné au préalable.
Pour appeler un répertoire comme ça, il faut franchement être sûr de soi (et des autres utilisateurs du système) sur la manipulation des syntaxes.
Enfin, Jacques va tester et nous rendre compte.
Absolument.
et en s'assurant que path ne se termine pas par un "", auquel cas il y aurait lieu de ne pas en ajouter un autre.
Il me semble que CurrentProject.Path renvoie une chaîne de caractères ne se terminant pas par un "".
J'avoue que j'avais oublié qu'il s'agissait d'une variable réservée. Disons que ça simplifie un peu. On teste la condition une fois pour toutes avant d'écrire la formule, au lieu de la tester à l'exécution.
Mon Access est sur une autre machine, alors je te fais confiance, path se termine par un "", donc SaveAs path + "Dossier Excel3ème Envoi.xls"
c'est si on n'avait pas eu de barre inverse à la fin de path qu'on aurait écrit Excl.SaveAs path + "Dossier Excel3ème Envoi.xls"
ceci signifie que le répertoire où se trouve la base Access contient un sous-répertoire DossierExcel, dans lequel on sauvegarde un fichier 3èmeEnvoi.xls
En toute rigueur, si la commande SaveAs porte sur un objet Excel, la discussion aurait plutôt eu sa place dans microsoft.public.fr.excel
sauf à avoir un doute sur le contenu de la variable path, qui se trouve être une propriété de la base Access.
qu'est-ce que ce guillemet fait devant path, je ne vois pas du tout.
Dans la formule que Jacques voudrait remplacer, qui marche apparemment et que je rappelle:
Excl.SaveAs "C:Documents and SettingsPropriétaireMes documentsBASE Partie applicativeDossier Excel3ème Envoi.xls"
Si je lis bien, en donnant un chemin absolu (c'est-à-dire démarrant à la racine du disque) ça fonctionne (ce qui élimine le problème de matériel ou de droits d'accès), mais il a un problème avec la syntaxe démarrant au répertoire de la base (c'est-à-dire dans l'exemple, "C:Documents and SettingsPropriétaireMes documentsBASEPartie applicative"), et pour parler franchement en regardant cette syntaxe avec le path derrière un guillemet je me demande comment il aurait pu ne pas avoir de problème.
la chaîne de caractères venant après SaveAs est bien encadrée par des guillemets.
C'est bien aussi pour ça que c'est après avoir mis en cause le guillemet devant path que j'ai mis en cause le double guillemet à la fin ;)
c'est si on n'avait pas eu de barre inverse à la fin de path qu'on
aurait écrit
Excl.SaveAs path + "Dossier Excel3ème Envoi.xls"
ceci signifie que le répertoire où se trouve la base Access contient un
sous-répertoire DossierExcel, dans lequel on sauvegarde un fichier
3èmeEnvoi.xls
__________________________________
Oui, c'est exactement ce que j'ai pensé.
"Gloops" <gloops@niark.invalid> a écrit dans le message de news:
%239szM3N3HHA.5796@TK2MSFTNGP05.phx.gbl...
Willi2004 a écrit, le 12/08/2007 13:01 :
Bonjour Gloops.
Le guillemet de la fin, c'est pour fermer le guillemet devant path.
On pourrait aussi écrire:
Excl.SaveAs "path" & "Dossier Excel3ème Envoi.xls"
Ou encore:
Excl.SaveAs "path" & "" & "Dossier Excel3ème Envoi.xls"
Oui, d'accord, mais si on a un répertoire qui s'appelle "path", utilisé
en chemin relatif sur le chemin par défaut, à quoi bon une concaténation ?
Il suffirait alors de dire "pathDossier Excel3ème Envoi.xls"
et là, si ça ne marche pas, c'est que le chemin par défaut n'a pas bien
été sélectionné au préalable.
Pour appeler un répertoire comme ça, il faut franchement être sûr de soi
(et des autres utilisateurs du système) sur la manipulation des syntaxes.
Enfin, Jacques va tester et nous rendre compte.
Absolument.
et en s'assurant que path ne se termine pas par un "", auquel
cas il y aurait lieu de ne pas en ajouter un autre.
Il me semble que CurrentProject.Path renvoie une chaîne de caractères ne
se
terminant pas par un "".
J'avoue que j'avais oublié qu'il s'agissait d'une variable réservée.
Disons que ça simplifie un peu. On teste la condition une fois pour
toutes avant d'écrire la formule, au lieu de la tester à l'exécution.
Mon Access est sur une autre machine, alors je te fais confiance, path
se termine par un "", donc
SaveAs path + "Dossier Excel3ème Envoi.xls"
c'est si on n'avait pas eu de barre inverse à la fin de path qu'on
aurait écrit
Excl.SaveAs path + "Dossier Excel3ème Envoi.xls"
ceci signifie que le répertoire où se trouve la base Access contient un
sous-répertoire DossierExcel, dans lequel on sauvegarde un fichier
3èmeEnvoi.xls
En toute rigueur, si la commande SaveAs porte sur un objet Excel, la
discussion aurait plutôt eu sa place dans
microsoft.public.fr.excel
sauf à avoir un doute sur le contenu de la variable path, qui se trouve
être une propriété de la base Access.
qu'est-ce que ce guillemet fait devant
path, je ne vois pas du tout.
Dans la formule que Jacques voudrait remplacer, qui marche apparemment et
que je rappelle:
Excl.SaveAs "C:Documents and SettingsPropriétaireMes documentsBASE
Partie applicativeDossier Excel3ème Envoi.xls"
Si je lis bien, en donnant un chemin absolu (c'est-à-dire démarrant à la
racine du disque) ça fonctionne (ce qui élimine le problème de matériel
ou de droits d'accès), mais il a un problème avec la syntaxe démarrant
au répertoire de la base (c'est-à-dire dans l'exemple, "C:Documents and
SettingsPropriétaireMes documentsBASEPartie applicative"), et pour
parler franchement en regardant cette syntaxe avec le path derrière un
guillemet je me demande comment il aurait pu ne pas avoir de problème.
la chaîne de caractères venant après SaveAs est bien encadrée par des
guillemets.
C'est bien aussi pour ça que c'est après avoir mis en cause le guillemet
devant path que j'ai mis en cause le double guillemet à la fin ;)
c'est si on n'avait pas eu de barre inverse à la fin de path qu'on aurait écrit
Excl.SaveAs path + "Dossier Excel3ème Envoi.xls"
ceci signifie que le répertoire où se trouve la base Access contient un sous-répertoire DossierExcel, dans lequel on sauvegarde un fichier 3èmeEnvoi.xls
__________________________________ Oui, c'est exactement ce que j'ai pensé.
"Gloops" a écrit dans le message de news: % Willi2004 a écrit, le 12/08/2007 13:01 :
Bonjour Gloops. Le guillemet de la fin, c'est pour fermer le guillemet devant path. On pourrait aussi écrire: Excl.SaveAs "path" & "Dossier Excel3ème Envoi.xls"
Ou encore: Excl.SaveAs "path" & "" & "Dossier Excel3ème Envoi.xls"
Oui, d'accord, mais si on a un répertoire qui s'appelle "path", utilisé en chemin relatif sur le chemin par défaut, à quoi bon une concaténation ?
Il suffirait alors de dire "pathDossier Excel3ème Envoi.xls" et là, si ça ne marche pas, c'est que le chemin par défaut n'a pas bien été sélectionné au préalable.
Pour appeler un répertoire comme ça, il faut franchement être sûr de soi (et des autres utilisateurs du système) sur la manipulation des syntaxes.
Enfin, Jacques va tester et nous rendre compte.
Absolument.
et en s'assurant que path ne se termine pas par un "", auquel cas il y aurait lieu de ne pas en ajouter un autre.
Il me semble que CurrentProject.Path renvoie une chaîne de caractères ne se terminant pas par un "".
J'avoue que j'avais oublié qu'il s'agissait d'une variable réservée. Disons que ça simplifie un peu. On teste la condition une fois pour toutes avant d'écrire la formule, au lieu de la tester à l'exécution.
Mon Access est sur une autre machine, alors je te fais confiance, path se termine par un "", donc SaveAs path + "Dossier Excel3ème Envoi.xls"
c'est si on n'avait pas eu de barre inverse à la fin de path qu'on aurait écrit Excl.SaveAs path + "Dossier Excel3ème Envoi.xls"
ceci signifie que le répertoire où se trouve la base Access contient un sous-répertoire DossierExcel, dans lequel on sauvegarde un fichier 3èmeEnvoi.xls
En toute rigueur, si la commande SaveAs porte sur un objet Excel, la discussion aurait plutôt eu sa place dans microsoft.public.fr.excel
sauf à avoir un doute sur le contenu de la variable path, qui se trouve être une propriété de la base Access.
qu'est-ce que ce guillemet fait devant path, je ne vois pas du tout.
Dans la formule que Jacques voudrait remplacer, qui marche apparemment et que je rappelle:
Excl.SaveAs "C:Documents and SettingsPropriétaireMes documentsBASE Partie applicativeDossier Excel3ème Envoi.xls"
Si je lis bien, en donnant un chemin absolu (c'est-à-dire démarrant à la racine du disque) ça fonctionne (ce qui élimine le problème de matériel ou de droits d'accès), mais il a un problème avec la syntaxe démarrant au répertoire de la base (c'est-à-dire dans l'exemple, "C:Documents and SettingsPropriétaireMes documentsBASEPartie applicative"), et pour parler franchement en regardant cette syntaxe avec le path derrière un guillemet je me demande comment il aurait pu ne pas avoir de problème.
la chaîne de caractères venant après SaveAs est bien encadrée par des guillemets.
C'est bien aussi pour ça que c'est après avoir mis en cause le guillemet devant path que j'ai mis en cause le double guillemet à la fin ;)
