conception d'un système d'impression à partir d'access (access vers rtf et pdf)

Bonjour Flo,

J'ai un problème de réflexion à vous soumettre... Voilà, je dois
imprimer une documentation papier très très très volumineuse à
partir de données qui seront stockées via un SGBD.
Ce que je cherche, ce n'est bien évidemment pas la solution,
mais des axes de réflexion.
Faut-il mieux faire SGBD --> XML --> RTF / PDF ?
SGBD -- via VB --> DOC ?
Ce qui me fait très peur, c'est le coût potentiel des mises à jour...

Le look du document final est-il si complexe que tu penses à l'export ?
Tu parles de SGBD mais si tu viens sur ce forum, il s'agit peut-être
d'Access ;-))
Dans ce cas un état ne ferait-il pas l'affaire ?
On arrive à faire des "catalogues" sympa et cela résoud le problème de mise
à jour.
Le volume (s'il s'agit du nombre de pages) n'intervient pas dans ce cas.

--
Tisane

Bonjour Tisane,

Le look du document final est-il si complexe que tu penses à l'export ?
Oui, le document est très complexe : insertion d'objets OLE,

utilisation de formules mathématiques, gestion d'en-tête et de pied
de page avec indice, gestion des barres d'indice (suivi des
modifications), gestion de la pagination selon s'il s'agit de feuilles
paires ou impaires...

Tu parles de SGBD mais si tu viens sur ce forum, il s'agit peut-être
d'Access ;-))
Pour le moement je fais une maquette sous ACCESS. Mais je me préoccupe

peu de savoir quel SGBD je retiendrais à la fin. Pour info, les IHM de
manipulation sont fait dans un autre langage afin de réaliser une
architecture 2-tiers (séparations données/traitement & affichage).

Dans ce cas un état ne ferait-il pas l'affaire ?
Un état ACCESS est loin de faire l'affaire. De plus, les états

s'exportent très mal vers Word (à première vue) : les lignes
disparaissent, la mise en page est aléatoire... Le seul "bon export"
des état semble être des snapshot ! Et le problème, c'est que l'on
ne peut pas les modifier par la suite.

On arrive à faire des "catalogues" sympa et cela résoud le problème de mise
à jour.
Qu'entends-tu par catalogue ? Tu parles d'Etats Access ?

Le volume (s'il s'agit du nombre de pages) n'intervient pas dans ce cas.
Pour ma part je l'indique car il semble qu'une solution type

SGBD-->XML-->PDF via FOP risque d'être très gourmande en temps. C'est
juste un paramètre a prendre en compte : tant qu'il ne faut pas
attendre 30jours pour avoir la version papier ;-)

Merci de ta participation dans cette réflexion : toute piste et bonne
à explorer...

Cordialement,

Flo.

Salut à tous,

Je suis un peu deçu que personne n'est déjà planché sur un sujet
similaire :-(
Je reste tout de même à votre écoute si vous avez des idées...
Peut-être faut-il que je pose la question sur un forum SGBD où les
gens n'ont pas l'habitude d'utiliser des états tout prêt.

Encore merci,

Flo.

Flox wrote:

Bonjour Tisane,

Le look du document final est-il si complexe que tu penses à l'export ?
Oui, le document est très complexe : insertion d'objets OLE,

utilisation de formules mathématiques, gestion d'en-tête et de pied
de page avec indice, gestion des barres d'indice (suivi des
modifications), gestion de la pagination selon s'il s'agit de feuilles
paires ou impaires...

Tu parles de SGBD mais si tu viens sur ce forum, il s'agit peut-être
d'Access ;-))
Pour le moement je fais une maquette sous ACCESS. Mais je me préoccupe

peu de savoir quel SGBD je retiendrais à la fin. Pour info, les IHM de
manipulation sont fait dans un autre langage afin de réaliser une
architecture 2-tiers (séparations données/traitement & affichage).

Dans ce cas un état ne ferait-il pas l'affaire ?
Un état ACCESS est loin de faire l'affaire. De plus, les états

s'exportent très mal vers Word (à première vue) : les lignes
disparaissent, la mise en page est aléatoire... Le seul "bon export"
des état semble être des snapshot ! Et le problème, c'est que l'on
ne peut pas les modifier par la suite.

On arrive à faire des "catalogues" sympa et cela résoud le problè me de mise
à jour.
Qu'entends-tu par catalogue ? Tu parles d'Etats Access ?

Le volume (s'il s'agit du nombre de pages) n'intervient pas dans ce cas.
Pour ma part je l'indique car il semble qu'une solution type

SGBD-->XML-->PDF via FOP risque d'être très gourmande en temps. C'est
juste un paramètre a prendre en compte : tant qu'il ne faut pas
attendre 30jours pour avoir la version papier ;-)

Merci de ta participation dans cette réflexion : toute piste et bonne
à explorer...

Cordialement,

Flo.

Flox wrote:

Salut à tous,

Je suis un peu deçu que personne n'est déjà planché sur un sujet
similaire :-(
Je reste tout de même à votre écoute si vous avez des idées...
Peut-être faut-il que je pose la question sur un forum SGBD où les
gens n'ont pas l'habitude d'utiliser des états tout prêt.

Encore merci,

Flo.

Flox wrote:

Bonjour Tisane,

Le look du document final est-il si complexe que tu penses à l'expo rt ?
Oui, le document est très complexe : insertion d'objets OLE,

utilisation de formules mathématiques, gestion d'en-tête et de pied
de page avec indice, gestion des barres d'indice (suivi des
modifications), gestion de la pagination selon s'il s'agit de feuilles
paires ou impaires...

Tu parles de SGBD mais si tu viens sur ce forum, il s'agit peut-être
d'Access ;-))
Pour le moement je fais une maquette sous ACCESS. Mais je me préoccupe

peu de savoir quel SGBD je retiendrais à la fin. Pour info, les IHM de
manipulation sont fait dans un autre langage afin de réaliser une
architecture 2-tiers (séparations données/traitement & affichage).

Dans ce cas un état ne ferait-il pas l'affaire ?
Un état ACCESS est loin de faire l'affaire. De plus, les états

s'exportent très mal vers Word (à première vue) : les lignes
disparaissent, la mise en page est aléatoire... Le seul "bon export"
des état semble être des snapshot ! Et le problème, c'est que l'on
ne peut pas les modifier par la suite.

On arrive à faire des "catalogues" sympa et cela résoud le probl ème de mise
à jour.
Qu'entends-tu par catalogue ? Tu parles d'Etats Access ?

Le volume (s'il s'agit du nombre de pages) n'intervient pas dans ce c as.
Pour ma part je l'indique car il semble qu'une solution type

SGBD-->XML-->PDF via FOP risque d'être très gourmande en temps. C'e st
juste un paramètre a prendre en compte : tant qu'il ne faut pas
attendre 30jours pour avoir la version papier ;-)

Merci de ta participation dans cette réflexion : toute piste et bonne
à explorer...

Cordialement,

Flo.

Bonjour,

Il faudrait plusieurs précisions :
quand tu dis que l'on peut modifier le document word ,tu comptes faire
une maj du SGDB
ou pas.
A part word il ya cristal report mais sans modification du document
final tu peux faire un etat que tu transformes en pdf ensuite.Il faut
voir la compléxité mais par vba tu peux faire pas mal de chose .
dans un projet je sortais un etat avec des fichiers word et excel avec
la gestion des pages c'est vrai que c'est un peu galére mais je suis
arrivé.


Voila !!!
a+
courage.
Pascal

Salut Pascal,

En fait, je veux pouvoir modifier le fichier type word dans le cas où
l'on commence de cette façon et que l'on abandonne le SGBD : avoir un
format exploitable directement. Il n'est donc pas envisagé de modifier
la BD à travers Word.

Et je pense que générer ma doc via vb n'est pas forcement réalisable
: la documentation est très hétérogène. Alors faire 1 ajouter pied
de page + ajouter 1 ligne de texte + ajouter un paragraphe risque
d'être trop fastidieux pour être réaliste. C'est pour cela que je
pense à XML...

Merci de ton aide ;-)

Flo.


pascal wrote:

Flox wrote:

Salut à tous,

Je suis un peu deçu que personne n'est déjà planché sur un sujet
similaire :-(
Je reste tout de même à votre écoute si vous avez des idées...
Peut-être faut-il que je pose la question sur un forum SGBD où les
gens n'ont pas l'habitude d'utiliser des états tout prêt.

Encore merci,

Flo.

Flox wrote:

Bonjour Tisane,

Le look du document final est-il si complexe que tu penses à l'ex port ?
Oui, le document est très complexe : insertion d'objets OLE,

utilisation de formules mathématiques, gestion d'en-tête et de pi ed
de page avec indice, gestion des barres d'indice (suivi des
modifications), gestion de la pagination selon s'il s'agit de feuilles
paires ou impaires...

Tu parles de SGBD mais si tu viens sur ce forum, il s'agit peut-ê tre
d'Access ;-))
Pour le moement je fais une maquette sous ACCESS. Mais je me préocc upe

peu de savoir quel SGBD je retiendrais à la fin. Pour info, les IHM de
manipulation sont fait dans un autre langage afin de réaliser une
architecture 2-tiers (séparations données/traitement & affichage).

Dans ce cas un état ne ferait-il pas l'affaire ?
Un état ACCESS est loin de faire l'affaire. De plus, les états

s'exportent très mal vers Word (à première vue) : les lignes
disparaissent, la mise en page est aléatoire... Le seul "bon export"
des état semble être des snapshot ! Et le problème, c'est que l 'on
ne peut pas les modifier par la suite.

On arrive à faire des "catalogues" sympa et cela résoud le prob lème de mise
à jour.
Qu'entends-tu par catalogue ? Tu parles d'Etats Access ?

Le volume (s'il s'agit du nombre de pages) n'intervient pas dans ce cas.
Pour ma part je l'indique car il semble qu'une solution type

SGBD-->XML-->PDF via FOP risque d'être très gourmande en temps. C 'est
juste un paramètre a prendre en compte : tant qu'il ne faut pas
attendre 30jours pour avoir la version papier ;-)

Merci de ta participation dans cette réflexion : toute piste et bon ne
à explorer...

Cordialement,

Flo.

Bonjour,

Il faudrait plusieurs précisions :
quand tu dis que l'on peut modifier le document word ,tu comptes faire
une maj du SGDB
ou pas.
A part word il ya cristal report mais sans modification du document
final tu peux faire un etat que tu transformes en pdf ensuite.Il faut
voir la compléxité mais par vba tu peux faire pas mal de chose .
dans un projet je sortais un etat avec des fichiers word et excel avec
la gestion des pages c'est vrai que c'est un peu galére mais je suis
arrivé.


Voila !!!
a+
courage.
Pascal