Là effectivement c'est plus délicat.
Si la table ne porte pas le même nom et que celle-ci ne contient pas les
mêmes champs (en genre et en nombre) c'est délicat mais pas irréalisable...
La problème va plancher sur votre degré de connaissance en VBA car il vous
faudra écrire un code qui enumère toutes les tables non système (à savoir une
seule) de manière à obtenir son nom.
Ensuite, il faudra pondre une routine de création dynamique de l'état
(CreateReport) fondé sur cette table avec ajout dynamique des contrôles
(CreateControl) en fonction des champs de la table en usant d'un jeu de
boucles imbriquées For Each/Next
Après quoi, il faudra enregistrer l'état, écrire la procédure PDF et lancer
son impression.
Enfin, détruire l'état (optionnel).
Voyez le cheminement, vu comme ça, c'est pas très compliqué mais il y a du
code à écrire et pas qu'un petit peu...
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentMe revoilà, désolé pour le temps de réponse mais je n'avais pas accès à
internet ce week end.
Concernant la démarche, il faudrait donc créer un état comme désooré avant
même d'avoir la table, puis importer la table voulue et l'associer à l'état
précedemment créé, c'est bien ca ? Cela ne nécessite t'il pas que toutes les
tables aient la même strucuture ?
Imaginez que j'ai 3000 tables différentes venant des 4 coins du monde, et
donc, n'ayant pas toutes la même structure. N'y a t'il pas un moyen simple de
les imprimer de façon propre et lisible rapidemment et sans les faire uns par
uns ?
N'hésitez pas à demander des préicsions si je ne suis pas assez clair, et
encore merci pour l'aide que vous m'apportez.
PS : Désolé pour le post précédent, petite erreur de manipulation.Bien disons que je vous dis cela parce que ne serait-ce que le code
nécessaire à générer silencieusement un PDF via Acrobat est un code musclé
utilisant des API's Windows, attaquant le Registre...entre autres ; quant à
VBA et Access, il est utile de maîtriser les méthodes pour créer et ouvrir un
état (dans votre cas).
Mes conseils ne développeront pas votre projet.
Il vous faut donc dans un 1er temps créer une base à partir de la copie de
ce que l'on vous fourni (avec la table en question).
De là, générer un état tel que souhaité à l'impression et vous entraîner à
automatiser via la méthode DoCmd.OpenReport, l'ouverture de votre état puis
son impression et enfin, quitter la base...
Une fois que vous aurez mis cela en place, on pourra continuer.
P.S. la table en question porte t-elle toujours le même nom ? Si oui, tant
mieux, sinon, ça complique un petit peu plus le code.
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentJe vois. Je n'ai pas vraiment de connaissances spécifiques à Access, VBA ou
DAO, mais pourquoi pas m'y interresser d'un peu plus près.
Si vous avez des conseils pour m'orienter, ce n'est pas de refus, ca
m'évitera de me plonger dans des choses dont je n'aurai pas forcément utilité.Eh bien si l'on vous fournis un mdb avec une table et que celle-ci est seule
il suffit de créer une petite application Access qui pourrait importer cette
table localement et du fait que cette petite appli contiendrait déjà un état,
il suffirait de lui affecter la table comme source puis de lancer
l'impression.
En fait il y a pas mal de possibilité mais il y a du travail tout de même...
Quel est votre degré de connaissance d'Access, du VBA et des objets DAO ?
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentBonjour,
L'idéal est le PDF plutôt que le RTF.
Voici une source ici :
http://access.developpez.com/sources/?page=Etat#ExportPDF
(Exporter un état en PDF)
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentBonjour,
Je cherche à créer des rapports depuis une base de données quelconque de
facon automatisée.
Mon but est en fait de pouvoir créer un outil permettant de générer un
rapport au format voulu ( RTF principalement ), avec le minimum d'interaction
humaine ( à priori juste lancer le programme et c'est tout ).
Si je me tourne vers Access, c'est principalement parce que les bases de
données en questions sont au format Access.
Est ce faisable selon vous ? Ou il y a t'il un moyen plus simple de le
faire, peut etre ? (Outils déjà existants ?)
Merci d'avance pour l'aide que vous saurez m'apporter.
Larry.
Là effectivement c'est plus délicat.
Si la table ne porte pas le même nom et que celle-ci ne contient pas les
mêmes champs (en genre et en nombre) c'est délicat mais pas irréalisable...
La problème va plancher sur votre degré de connaissance en VBA car il vous
faudra écrire un code qui enumère toutes les tables non système (à savoir une
seule) de manière à obtenir son nom.
Ensuite, il faudra pondre une routine de création dynamique de l'état
(CreateReport) fondé sur cette table avec ajout dynamique des contrôles
(CreateControl) en fonction des champs de la table en usant d'un jeu de
boucles imbriquées For Each/Next
Après quoi, il faudra enregistrer l'état, écrire la procédure PDF et lancer
son impression.
Enfin, détruire l'état (optionnel).
Voyez le cheminement, vu comme ça, c'est pas très compliqué mais il y a du
code à écrire et pas qu'un petit peu...
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemment
Me revoilà, désolé pour le temps de réponse mais je n'avais pas accès à
internet ce week end.
Concernant la démarche, il faudrait donc créer un état comme désooré avant
même d'avoir la table, puis importer la table voulue et l'associer à l'état
précedemment créé, c'est bien ca ? Cela ne nécessite t'il pas que toutes les
tables aient la même strucuture ?
Imaginez que j'ai 3000 tables différentes venant des 4 coins du monde, et
donc, n'ayant pas toutes la même structure. N'y a t'il pas un moyen simple de
les imprimer de façon propre et lisible rapidemment et sans les faire uns par
uns ?
N'hésitez pas à demander des préicsions si je ne suis pas assez clair, et
encore merci pour l'aide que vous m'apportez.
PS : Désolé pour le post précédent, petite erreur de manipulation.
Bien disons que je vous dis cela parce que ne serait-ce que le code
nécessaire à générer silencieusement un PDF via Acrobat est un code musclé
utilisant des API's Windows, attaquant le Registre...entre autres ; quant à
VBA et Access, il est utile de maîtriser les méthodes pour créer et ouvrir un
état (dans votre cas).
Mes conseils ne développeront pas votre projet.
Il vous faut donc dans un 1er temps créer une base à partir de la copie de
ce que l'on vous fourni (avec la table en question).
De là, générer un état tel que souhaité à l'impression et vous entraîner à
automatiser via la méthode DoCmd.OpenReport, l'ouverture de votre état puis
son impression et enfin, quitter la base...
Une fois que vous aurez mis cela en place, on pourra continuer.
P.S. la table en question porte t-elle toujours le même nom ? Si oui, tant
mieux, sinon, ça complique un petit peu plus le code.
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemment
Je vois. Je n'ai pas vraiment de connaissances spécifiques à Access, VBA ou
DAO, mais pourquoi pas m'y interresser d'un peu plus près.
Si vous avez des conseils pour m'orienter, ce n'est pas de refus, ca
m'évitera de me plonger dans des choses dont je n'aurai pas forcément utilité.
Eh bien si l'on vous fournis un mdb avec une table et que celle-ci est seule
il suffit de créer une petite application Access qui pourrait importer cette
table localement et du fait que cette petite appli contiendrait déjà un état,
il suffirait de lui affecter la table comme source puis de lancer
l'impression.
En fait il y a pas mal de possibilité mais il y a du travail tout de même...
Quel est votre degré de connaissance d'Access, du VBA et des objets DAO ?
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemment
Bonjour,
L'idéal est le PDF plutôt que le RTF.
Voici une source ici :
http://access.developpez.com/sources/?page=Etat#ExportPDF
(Exporter un état en PDF)
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemment
Bonjour,
Je cherche à créer des rapports depuis une base de données quelconque de
facon automatisée.
Mon but est en fait de pouvoir créer un outil permettant de générer un
rapport au format voulu ( RTF principalement ), avec le minimum d'interaction
humaine ( à priori juste lancer le programme et c'est tout ).
Si je me tourne vers Access, c'est principalement parce que les bases de
données en questions sont au format Access.
Est ce faisable selon vous ? Ou il y a t'il un moyen plus simple de le
faire, peut etre ? (Outils déjà existants ?)
Merci d'avance pour l'aide que vous saurez m'apporter.
Larry.
Là effectivement c'est plus délicat.
Si la table ne porte pas le même nom et que celle-ci ne contient pas les
mêmes champs (en genre et en nombre) c'est délicat mais pas irréalisable...
La problème va plancher sur votre degré de connaissance en VBA car il vous
faudra écrire un code qui enumère toutes les tables non système (à savoir une
seule) de manière à obtenir son nom.
Ensuite, il faudra pondre une routine de création dynamique de l'état
(CreateReport) fondé sur cette table avec ajout dynamique des contrôles
(CreateControl) en fonction des champs de la table en usant d'un jeu de
boucles imbriquées For Each/Next
Après quoi, il faudra enregistrer l'état, écrire la procédure PDF et lancer
son impression.
Enfin, détruire l'état (optionnel).
Voyez le cheminement, vu comme ça, c'est pas très compliqué mais il y a du
code à écrire et pas qu'un petit peu...
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentMe revoilà, désolé pour le temps de réponse mais je n'avais pas accès à
internet ce week end.
Concernant la démarche, il faudrait donc créer un état comme désooré avant
même d'avoir la table, puis importer la table voulue et l'associer à l'état
précedemment créé, c'est bien ca ? Cela ne nécessite t'il pas que toutes les
tables aient la même strucuture ?
Imaginez que j'ai 3000 tables différentes venant des 4 coins du monde, et
donc, n'ayant pas toutes la même structure. N'y a t'il pas un moyen simple de
les imprimer de façon propre et lisible rapidemment et sans les faire uns par
uns ?
N'hésitez pas à demander des préicsions si je ne suis pas assez clair, et
encore merci pour l'aide que vous m'apportez.
PS : Désolé pour le post précédent, petite erreur de manipulation.Bien disons que je vous dis cela parce que ne serait-ce que le code
nécessaire à générer silencieusement un PDF via Acrobat est un code musclé
utilisant des API's Windows, attaquant le Registre...entre autres ; quant à
VBA et Access, il est utile de maîtriser les méthodes pour créer et ouvrir un
état (dans votre cas).
Mes conseils ne développeront pas votre projet.
Il vous faut donc dans un 1er temps créer une base à partir de la copie de
ce que l'on vous fourni (avec la table en question).
De là, générer un état tel que souhaité à l'impression et vous entraîner à
automatiser via la méthode DoCmd.OpenReport, l'ouverture de votre état puis
son impression et enfin, quitter la base...
Une fois que vous aurez mis cela en place, on pourra continuer.
P.S. la table en question porte t-elle toujours le même nom ? Si oui, tant
mieux, sinon, ça complique un petit peu plus le code.
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentJe vois. Je n'ai pas vraiment de connaissances spécifiques à Access, VBA ou
DAO, mais pourquoi pas m'y interresser d'un peu plus près.
Si vous avez des conseils pour m'orienter, ce n'est pas de refus, ca
m'évitera de me plonger dans des choses dont je n'aurai pas forcément utilité.Eh bien si l'on vous fournis un mdb avec une table et que celle-ci est seule
il suffit de créer une petite application Access qui pourrait importer cette
table localement et du fait que cette petite appli contiendrait déjà un état,
il suffirait de lui affecter la table comme source puis de lancer
l'impression.
En fait il y a pas mal de possibilité mais il y a du travail tout de même...
Quel est votre degré de connaissance d'Access, du VBA et des objets DAO ?
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentBonjour,
L'idéal est le PDF plutôt que le RTF.
Voici une source ici :
http://access.developpez.com/sources/?page=Etat#ExportPDF
(Exporter un état en PDF)
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentBonjour,
Je cherche à créer des rapports depuis une base de données quelconque de
facon automatisée.
Mon but est en fait de pouvoir créer un outil permettant de générer un
rapport au format voulu ( RTF principalement ), avec le minimum d'interaction
humaine ( à priori juste lancer le programme et c'est tout ).
Si je me tourne vers Access, c'est principalement parce que les bases de
données en questions sont au format Access.
Est ce faisable selon vous ? Ou il y a t'il un moyen plus simple de le
faire, peut etre ? (Outils déjà existants ?)
Merci d'avance pour l'aide que vous saurez m'apporter.
Larry.
Mais il n'y a pas moyen de réutiliser le code des assistants, qui ma foi,
font très bien le travail, juste un peu trop interactivement ?
J'arrive à récupérer les noms des tables non systèmes et à créer un rapport
vide pour l'instant. Il faudrait maintenant que je remplisse ce rapport, de
la même façon que le fait l'assistant (autoreport : Columnar). S'il était
possible de le réutiliser d'un manière ou d'une autre, ça accelèrerait les
choses, je pense.Là effectivement c'est plus délicat.
Si la table ne porte pas le même nom et que celle-ci ne contient pas les
mêmes champs (en genre et en nombre) c'est délicat mais pas irréalisable...
La problème va plancher sur votre degré de connaissance en VBA car il vous
faudra écrire un code qui enumère toutes les tables non système (à savoir une
seule) de manière à obtenir son nom.
Ensuite, il faudra pondre une routine de création dynamique de l'état
(CreateReport) fondé sur cette table avec ajout dynamique des contrôles
(CreateControl) en fonction des champs de la table en usant d'un jeu de
boucles imbriquées For Each/Next
Après quoi, il faudra enregistrer l'état, écrire la procédure PDF et lancer
son impression.
Enfin, détruire l'état (optionnel).
Voyez le cheminement, vu comme ça, c'est pas très compliqué mais il y a du
code à écrire et pas qu'un petit peu...
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentMe revoilà, désolé pour le temps de réponse mais je n'avais pas accès à
internet ce week end.
Concernant la démarche, il faudrait donc créer un état comme désooré avant
même d'avoir la table, puis importer la table voulue et l'associer à l'état
précedemment créé, c'est bien ca ? Cela ne nécessite t'il pas que toutes les
tables aient la même strucuture ?
Imaginez que j'ai 3000 tables différentes venant des 4 coins du monde, et
donc, n'ayant pas toutes la même structure. N'y a t'il pas un moyen simple de
les imprimer de façon propre et lisible rapidemment et sans les faire uns par
uns ?
N'hésitez pas à demander des préicsions si je ne suis pas assez clair, et
encore merci pour l'aide que vous m'apportez.
PS : Désolé pour le post précédent, petite erreur de manipulation.Bien disons que je vous dis cela parce que ne serait-ce que le code
nécessaire à générer silencieusement un PDF via Acrobat est un code musclé
utilisant des API's Windows, attaquant le Registre...entre autres ; quant à
VBA et Access, il est utile de maîtriser les méthodes pour créer et ouvrir un
état (dans votre cas).
Mes conseils ne développeront pas votre projet.
Il vous faut donc dans un 1er temps créer une base à partir de la copie de
ce que l'on vous fourni (avec la table en question).
De là, générer un état tel que souhaité à l'impression et vous entraîner à
automatiser via la méthode DoCmd.OpenReport, l'ouverture de votre état puis
son impression et enfin, quitter la base...
Une fois que vous aurez mis cela en place, on pourra continuer.
P.S. la table en question porte t-elle toujours le même nom ? Si oui, tant
mieux, sinon, ça complique un petit peu plus le code.
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentJe vois. Je n'ai pas vraiment de connaissances spécifiques à Access, VBA ou
DAO, mais pourquoi pas m'y interresser d'un peu plus près.
Si vous avez des conseils pour m'orienter, ce n'est pas de refus, ca
m'évitera de me plonger dans des choses dont je n'aurai pas forcément utilité.Eh bien si l'on vous fournis un mdb avec une table et que celle-ci est seule
il suffit de créer une petite application Access qui pourrait importer cette
table localement et du fait que cette petite appli contiendrait déjà un état,
il suffirait de lui affecter la table comme source puis de lancer
l'impression.
En fait il y a pas mal de possibilité mais il y a du travail tout de même...
Quel est votre degré de connaissance d'Access, du VBA et des objets DAO ?
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentBonjour,
L'idéal est le PDF plutôt que le RTF.
Voici une source ici :
http://access.developpez.com/sources/?page=Etat#ExportPDF
(Exporter un état en PDF)
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentBonjour,
Je cherche à créer des rapports depuis une base de données quelconque de
facon automatisée.
Mon but est en fait de pouvoir créer un outil permettant de générer un
rapport au format voulu ( RTF principalement ), avec le minimum d'interaction
humaine ( à priori juste lancer le programme et c'est tout ).
Si je me tourne vers Access, c'est principalement parce que les bases de
données en questions sont au format Access.
Est ce faisable selon vous ? Ou il y a t'il un moyen plus simple de le
faire, peut etre ? (Outils déjà existants ?)
Merci d'avance pour l'aide que vous saurez m'apporter.
Larry.
Mais il n'y a pas moyen de réutiliser le code des assistants, qui ma foi,
font très bien le travail, juste un peu trop interactivement ?
J'arrive à récupérer les noms des tables non systèmes et à créer un rapport
vide pour l'instant. Il faudrait maintenant que je remplisse ce rapport, de
la même façon que le fait l'assistant (autoreport : Columnar). S'il était
possible de le réutiliser d'un manière ou d'une autre, ça accelèrerait les
choses, je pense.
Là effectivement c'est plus délicat.
Si la table ne porte pas le même nom et que celle-ci ne contient pas les
mêmes champs (en genre et en nombre) c'est délicat mais pas irréalisable...
La problème va plancher sur votre degré de connaissance en VBA car il vous
faudra écrire un code qui enumère toutes les tables non système (à savoir une
seule) de manière à obtenir son nom.
Ensuite, il faudra pondre une routine de création dynamique de l'état
(CreateReport) fondé sur cette table avec ajout dynamique des contrôles
(CreateControl) en fonction des champs de la table en usant d'un jeu de
boucles imbriquées For Each/Next
Après quoi, il faudra enregistrer l'état, écrire la procédure PDF et lancer
son impression.
Enfin, détruire l'état (optionnel).
Voyez le cheminement, vu comme ça, c'est pas très compliqué mais il y a du
code à écrire et pas qu'un petit peu...
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemment
Me revoilà, désolé pour le temps de réponse mais je n'avais pas accès à
internet ce week end.
Concernant la démarche, il faudrait donc créer un état comme désooré avant
même d'avoir la table, puis importer la table voulue et l'associer à l'état
précedemment créé, c'est bien ca ? Cela ne nécessite t'il pas que toutes les
tables aient la même strucuture ?
Imaginez que j'ai 3000 tables différentes venant des 4 coins du monde, et
donc, n'ayant pas toutes la même structure. N'y a t'il pas un moyen simple de
les imprimer de façon propre et lisible rapidemment et sans les faire uns par
uns ?
N'hésitez pas à demander des préicsions si je ne suis pas assez clair, et
encore merci pour l'aide que vous m'apportez.
PS : Désolé pour le post précédent, petite erreur de manipulation.
Bien disons que je vous dis cela parce que ne serait-ce que le code
nécessaire à générer silencieusement un PDF via Acrobat est un code musclé
utilisant des API's Windows, attaquant le Registre...entre autres ; quant à
VBA et Access, il est utile de maîtriser les méthodes pour créer et ouvrir un
état (dans votre cas).
Mes conseils ne développeront pas votre projet.
Il vous faut donc dans un 1er temps créer une base à partir de la copie de
ce que l'on vous fourni (avec la table en question).
De là, générer un état tel que souhaité à l'impression et vous entraîner à
automatiser via la méthode DoCmd.OpenReport, l'ouverture de votre état puis
son impression et enfin, quitter la base...
Une fois que vous aurez mis cela en place, on pourra continuer.
P.S. la table en question porte t-elle toujours le même nom ? Si oui, tant
mieux, sinon, ça complique un petit peu plus le code.
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemment
Je vois. Je n'ai pas vraiment de connaissances spécifiques à Access, VBA ou
DAO, mais pourquoi pas m'y interresser d'un peu plus près.
Si vous avez des conseils pour m'orienter, ce n'est pas de refus, ca
m'évitera de me plonger dans des choses dont je n'aurai pas forcément utilité.
Eh bien si l'on vous fournis un mdb avec une table et que celle-ci est seule
il suffit de créer une petite application Access qui pourrait importer cette
table localement et du fait que cette petite appli contiendrait déjà un état,
il suffirait de lui affecter la table comme source puis de lancer
l'impression.
En fait il y a pas mal de possibilité mais il y a du travail tout de même...
Quel est votre degré de connaissance d'Access, du VBA et des objets DAO ?
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemment
Bonjour,
L'idéal est le PDF plutôt que le RTF.
Voici une source ici :
http://access.developpez.com/sources/?page=Etat#ExportPDF
(Exporter un état en PDF)
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemment
Bonjour,
Je cherche à créer des rapports depuis une base de données quelconque de
facon automatisée.
Mon but est en fait de pouvoir créer un outil permettant de générer un
rapport au format voulu ( RTF principalement ), avec le minimum d'interaction
humaine ( à priori juste lancer le programme et c'est tout ).
Si je me tourne vers Access, c'est principalement parce que les bases de
données en questions sont au format Access.
Est ce faisable selon vous ? Ou il y a t'il un moyen plus simple de le
faire, peut etre ? (Outils déjà existants ?)
Merci d'avance pour l'aide que vous saurez m'apporter.
Larry.
Mais il n'y a pas moyen de réutiliser le code des assistants, qui ma foi,
font très bien le travail, juste un peu trop interactivement ?
J'arrive à récupérer les noms des tables non systèmes et à créer un rapport
vide pour l'instant. Il faudrait maintenant que je remplisse ce rapport, de
la même façon que le fait l'assistant (autoreport : Columnar). S'il était
possible de le réutiliser d'un manière ou d'une autre, ça accelèrerait les
choses, je pense.Là effectivement c'est plus délicat.
Si la table ne porte pas le même nom et que celle-ci ne contient pas les
mêmes champs (en genre et en nombre) c'est délicat mais pas irréalisable...
La problème va plancher sur votre degré de connaissance en VBA car il vous
faudra écrire un code qui enumère toutes les tables non système (à savoir une
seule) de manière à obtenir son nom.
Ensuite, il faudra pondre une routine de création dynamique de l'état
(CreateReport) fondé sur cette table avec ajout dynamique des contrôles
(CreateControl) en fonction des champs de la table en usant d'un jeu de
boucles imbriquées For Each/Next
Après quoi, il faudra enregistrer l'état, écrire la procédure PDF et lancer
son impression.
Enfin, détruire l'état (optionnel).
Voyez le cheminement, vu comme ça, c'est pas très compliqué mais il y a du
code à écrire et pas qu'un petit peu...
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentMe revoilà, désolé pour le temps de réponse mais je n'avais pas accès à
internet ce week end.
Concernant la démarche, il faudrait donc créer un état comme désooré avant
même d'avoir la table, puis importer la table voulue et l'associer à l'état
précedemment créé, c'est bien ca ? Cela ne nécessite t'il pas que toutes les
tables aient la même strucuture ?
Imaginez que j'ai 3000 tables différentes venant des 4 coins du monde, et
donc, n'ayant pas toutes la même structure. N'y a t'il pas un moyen simple de
les imprimer de façon propre et lisible rapidemment et sans les faire uns par
uns ?
N'hésitez pas à demander des préicsions si je ne suis pas assez clair, et
encore merci pour l'aide que vous m'apportez.
PS : Désolé pour le post précédent, petite erreur de manipulation.Bien disons que je vous dis cela parce que ne serait-ce que le code
nécessaire à générer silencieusement un PDF via Acrobat est un code musclé
utilisant des API's Windows, attaquant le Registre...entre autres ; quant à
VBA et Access, il est utile de maîtriser les méthodes pour créer et ouvrir un
état (dans votre cas).
Mes conseils ne développeront pas votre projet.
Il vous faut donc dans un 1er temps créer une base à partir de la copie de
ce que l'on vous fourni (avec la table en question).
De là, générer un état tel que souhaité à l'impression et vous entraîner à
automatiser via la méthode DoCmd.OpenReport, l'ouverture de votre état puis
son impression et enfin, quitter la base...
Une fois que vous aurez mis cela en place, on pourra continuer.
P.S. la table en question porte t-elle toujours le même nom ? Si oui, tant
mieux, sinon, ça complique un petit peu plus le code.
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentJe vois. Je n'ai pas vraiment de connaissances spécifiques à Access, VBA ou
DAO, mais pourquoi pas m'y interresser d'un peu plus près.
Si vous avez des conseils pour m'orienter, ce n'est pas de refus, ca
m'évitera de me plonger dans des choses dont je n'aurai pas forcément utilité.Eh bien si l'on vous fournis un mdb avec une table et que celle-ci est seule
il suffit de créer une petite application Access qui pourrait importer cette
table localement et du fait que cette petite appli contiendrait déjà un état,
il suffirait de lui affecter la table comme source puis de lancer
l'impression.
En fait il y a pas mal de possibilité mais il y a du travail tout de même...
Quel est votre degré de connaissance d'Access, du VBA et des objets DAO ?
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentBonjour,
L'idéal est le PDF plutôt que le RTF.
Voici une source ici :
http://access.developpez.com/sources/?page=Etat#ExportPDF
(Exporter un état en PDF)
--
Argy
http://argyronet.developpez.com/
Ce qui donne son sens à la communication, c´est la réponse que l´on obtient.
Si vous n´obtenez pas la réponse voulue, communiquez différemmentBonjour,
Je cherche à créer des rapports depuis une base de données quelconque de
facon automatisée.
Mon but est en fait de pouvoir créer un outil permettant de générer un
rapport au format voulu ( RTF principalement ), avec le minimum d'interaction
humaine ( à priori juste lancer le programme et c'est tout ).
Si je me tourne vers Access, c'est principalement parce que les bases de
données en questions sont au format Access.
Est ce faisable selon vous ? Ou il y a t'il un moyen plus simple de le
faire, peut etre ? (Outils déjà existants ?)
Merci d'avance pour l'aide que vous saurez m'apporter.
Larry.
