 1 membre
Connectés : ( personne )
 - La Charte du Forum - Forum
 - Questions générale
 Sujet n° 516 |
IMPRIMER EN PDF AVEC PDFCREATOR |
le 24/05/2011 : 14:45
par PAT77
visiteur
|
Bonjour
Dans une Bd, lorsque j'imprime un état (une facture), je veux l'imprimer en pdf également pour archivage. J'ai trouvé le code avec PDFCREATOR. Cela fonctionne mais dès que je copie ma BD sur un autre poste, j'ai des bugs avec la fonction "date". I faut décocher et recocher les références pour tout remettre d'équerre.
A priori , j'ai trouvé sur le net ce genre de pbe pour des base en mde, mais je n'ai pas trouvé la solution jointe. Merci d'avance pour vos solutions |
|
|  
|
Réponse n° 1
--------
le 24/05/2011 : 15:10
par 3Stone
Administrateur
|
Bonjour,
Citation :mais dès que je copie ma BD sur un autre poste, j'ai des bugs avec la fonction "date". I faut décocher et recocher les références pour tout remettre d'équerre.
L'impression n'a rien a voir avec ce problème de référence!
Au démarrage d'une base, au chargement du code, Access vérifie toutes les révérences, et en cas de problème, se plaint sur de références "basiques" comme la fonction Date(), Left(), etc.
Cela indique simplement que sur le poste incriminé, au moins une référence crée problème. Il faut dans ce cas vérifier quelle référence est marquée "Manquante" dans la liste (Alt + F11, menu Outils, Références).
Il suffit en général de décocher cette référence marquée "Manquante" et compiler le code pour vérifier que tout rentre dans l'ordre.
Un conseil:
Il ne faut jamais cocher des références non nécessaires au bon fonctionnement de la base. Le mieux étant de tout décocher, et de ne recocher que celle exigée par la base.
Cordialement,
Pierre(3stone) |
|
|
|
Réponse n° 2
--------
le 24/05/2011 : 15:32
par PAT77
visiteur
|
Merci de prendre le temps de me répondre.
Je fais des améliorations sur ma base. Pour plus de facilité, je travaille sur une clé. Dès que je change de poste, ça bug, je dois cocher/décocher et ensuite c'est ok. Mais si je change de poste, de nouveau ça bug.
Après analyse des différentes sauvegardes, j'ai ce problème depuis que j'ai modifié un formulaire pour imprimer en pdf.
J'ai trouvé ici le code
http://grenier.self-access.com/?post/2008/05/07/Automatiser-limpression-dun-etat-en-PDF-via-PDFCreator
Ici j'ai vu que ce pbe existait
http://groupes.codes-sources.com/article-access-2003-probleme-fonction-date-reference-pdf-creator-472737.aspx |
|
|
|
Réponse n° 3
--------
le 24/05/2011 : 16:50
par 3Stone
Administrateur
|
Bonjour,
Citation : Pour plus de facilité, je travaille sur une clé.
Ce n'est définitivement pas une bonne méthode pour utiliser une base 
Une base, idéalement scindée en frontale (l'application) et dorsale (les tables avec les données) se doit d'être installée sur un PC (ou portable).
Seul les données peuvent être "baladées" en utilisant un code tel que celui-ci pour reconnecter les tables.
Citation :J'ai trouvé ici le code
http://grenier.self-access.com/?post/2008/05/07/Automatiser-limpression-dun-etat-en-PDF-via-PDFCreator
Je connais le site du copain Hervé Inisan 
Ceci dit, cette méthode date depuis des lustres, et même si elle fonctionne toujours, il y a actuellement d'autres outils gratuits pour créer des PDF 
Citation :Ici j'ai vu que ce pbe existait
http://groupes.codes-sources.com/article-access-2003-probleme-fonction-date-reference-pdf-creator-472737.aspx
Non, cela ne concernait pas PDF Creator, mais le fait que le demandeur travaillait sous "Runtime Access" !
Donc, je répète que l'on ne trimbale pas un application Access (comme on balladerai un bête fichier Word). Et si cela est nécessaire pour une bonne raison, il faut à chaque lancement vérifier les références et surtout, décocher les inutiles.
Cordialement,
Pierre(3stone) |
|
|
|
Réponse n° 4
--------
le 24/05/2011 : 17:28
par PAT77
visiteur
|
J'utilise effectivement une base frontale sur plusieurs poste et une base (données) sur un seul pc.
Afin de continuer le développement, j'ai une copie sur une clé, ce qui me permet de travailler n'importe où, même chez moi.
Si cette méthode de pdf est obsolète que dois-je utiliser ? |
|
|
|
Réponse n° 5
--------
le 24/05/2011 : 17:56
par 3Stone
Administrateur
|
Citation : Afin de continuer le développement, j'ai une copie sur une clé, ce qui me permet de travailler n'importe où, même chez moi
Cela reste du développement "continu", et il faut faire les vérifications comme dit plus haut...
Citation :Si cette méthode de pdf est obsolète que dois-je utiliser ?
J'ai dit qu'elle datait, mais fonctionne toujours... et même sous Win 7 semble t-il.
Le but d'un programme, est qu'il fasse ce que l'on attend de lui. Si tu es satisfait, il n'y a pas de raison pour en changer.
Cordialement,
Pierre(3stone) |
|
|
|
Réponse n° 6
--------
le 24/05/2011 : 21:07
par PAT77
visiteur
|
Je tente de contrôler au maximum. C'est pourquoi, je fais mes tests sur plusieurs postes dans des configs différentes avant de mettre en place la nouvelle version.
A priori, ce que je fais avec PDFCREATOR me plait. Je l'utilise parce que j'ai trouvé ce code pour le mettre en pratique, je suis preneur si il y a d'autres solutions.
Mais mon problème n'est pas résolu sur cette notion de référence. Si je reviens à la version N-1 avant ce code, pas de soucis. Avec ce code, il faut cocher/decocher. Cela dépasse largement mes compétences. Cela fait très longtemps que je développe petit à petit cette BD pour la boite, je n'ai jamais rencontré ce cas. Où dois-je chercher le soucis ? |
|
|
|
Réponse n° 7
--------
le 25/05/2011 : 12:25
par 3Stone
Administrateur
|
Bonjour,
Citation :Je tente de contrôler au maximum. C'est pourquoi, je fais mes tests sur plusieurs postes dans des configs différentes avant de mettre en place la nouvelle version.
Je me demande s'il n'y a pas une méprise...
Une base Access est liée à son environnement, et d'autant plus que cet environnement consiste en des versions différentes de l'OS. Cela ne veux pas dire qu'une base ne tourne pas sous des OS différent, mais une fois mise en place, sa "configuration" lui devient propre et n'est pas forcément identique à sa voisine.
Cela vient du fait qu'une base Access n'est pas une application monolitique, mais utilise les DLL et autres composants apportés par Windows, et cela crée les problème remarqués, surtout lorsque l'on utilise des composants barbares.
Cette configuration, cette adaptation aux différents versions des DLL selon l'environnement se fait "normalement" de façon automatique... mais pas toujours.
La cause du problème est variable: versions trop disparate, emplacement, déclaration, versions multiples...
La première mesure à prendre pour éviter cela au maximum est de ne pas utiliser de composant externe, et au besoin, utiliser en priorité les API, nettement plus stable dans le temps. Préférer également le code VBA à un appel à un composant externe non standard.
Citation :Mais mon problème n'est pas résolu sur cette notion de référence. Si je reviens à la version N-1 avant ce code, pas de soucis.
Oui, mais que fait ce code et surtout :
- qu'elle extension est utilisée par ce code ?
- quel OS utilisés par les différentes machines ?
- quelle version d'Access ?
Cordialement,
Pierre(3stone) |
|
|
|
Réponse n° 8
--------
le 25/05/2011 : 13:09
par PAT77
visiteur
|
Merci pour les conseils.
Tous mes postes sont en XP avec access2000.
Mon soucis vient avec ce code récupéré sur ce site. Je veux juste lorsque j'imprime un état, lancer en tache cachée une impression de cet état en pdf pour archivage.
Ca fonctionne bien hormis ce fait de recocher au 1er démarrage.
qu'elle extension est utilisée par ce code ? --> je ne comprends pas cette question |
|
|
|
 sujet actif
sujet clos
 Important!
 Nouveau message -
 Rectifier message
 Clôturer sujet
 Remonter
|
© 2004-2013 
