Discussion :

[karpi]

Bonjour à tous,

J'ai hésité à poster ce message dans "Access", mais je trouve cet espace plus approprié, si ce n'est pas le cas, merci de me réorienter vers la bonne rubrique.

Je vais essayer d'être le plus clair possible pour obtenir de l'aide.

Notre société, bureau d'études, répond souvent à des appels d'offre internationaux. Dans les propositions techniques, nous présentons des références pour démontrer que nous avons déjà travaillé sur des projets similaires. Ces références sont présentées sous forme de fiches références, dont le format imposé varie selon le bailleur (le client).

Pour ne pas devoir dupliquer ces fiches dans chaque format nous avons créé une base de données avec Access avec des formulaires de saisie, et 3 boutons (1 bouton par format) nous permettant de générer directement la fiche souhaitée au format souhaité (celui du client).

Ça fonctionne plutôt bien, et même particulièrement bien entre Access et Word (normal me direz vous...) mais ce système a ses limites.

En effet, nous avons plusieurs bureaux, 1 en France, 3 à l'étranger, et 1 personne en télétravail en France. Si bien que le principal risque est l'éclatement de l'information : quelqu'un enregistre une nouvelle référence et oublie de partager la BDD mise à jour à tous les bureaux et c'est le début de la fin...

Pour éviter cela, il apparaît clairement qu'une BDD stockée sur un serveur en ligne serait idéale:
- possibilité en créant un formulaire de saisie que tout employé puisse saisir une nouvelle référence dans une BDD commune sur un serveur fournit par un hébergeur
- cela éviterait la duplication de BDD qui inévitablement aura plusieurs versions à un moment ou un autre.

Maintenant, mon principal problème est la connaissance à ce niveau, je précise que si j'ai qqs connaissances dans le domaine des SI, je ne suis ni développeur, ni gestionnaire de BDD. En fait je suis ingénieur dans un tout autre domaine (agronomie).

Est-ce qu'en mettant les données sur un serveur type MySQL, PostgreSQL, ou autre, il est également possible de générer facilement le fichier word qui va bien : fiche au bon format sans galère de mise en forme ?

Il y a visiblement la possibilité de mettre une base Access en ligne avec Sharepoint, mais honnêtement je n'y ai pas compris grand chose...

D'avance merci pour vos commentaires et conseils éclairés.

[StringBuilder]

Bonjour,

Access permet de manipuler des données à travers ODBC.
Ainsi, dans Access, vous manipulez des tables qui sont en réalité stockées sur un autre serveur.

Je pense que c'est cette solution qui sera la plus aisée à mettre en place chez vous, puisqu'elle vous évite de trop toucher à l'existant.

Sinon, transformer le résultat d'une requête en un document Word, ou autre, est toujours assez complexe à faire, surtout si on souhaite se passer d'un logiciel hors de prix pour le faire.

Word peut lui aussi directement pomper ses donner à travers un lien ODBC. Donc si vous choisissez d'abandonner Access et ses formulaires, au profit d'une nouvelle application, vous devriez toujours être en mesure de faire des fusions Word à partir de la nouvelle base de données.

Dans tous les cas, vous aurez besoin de vous faire aider par des personnes qui maîtrisent le sujet : la plupart des prestataires informatique n'ont pas la moindre idée de ce dont je suis en train de vous parler, et moi-même je sais que ça existe, sans être certain de la marche à suivre pour le faire tomber en marche.

[karpi]

Merci,

Access permet de manipuler des données à travers ODBC.
Ainsi, dans Access, vous manipulez des tables qui sont en réalité stockées sur un autre serveur.

Je pense que c'est cette solution qui sera la plus aisée à mettre en place chez vous, puisqu'elle vous évite de trop toucher à l'existant.

OK, donc la BDD en local est transférée sur un serveur (MySQL, PostgreSQL ou autre), et depuis access il est possible:
- à partir du formulaire de saisie d'enregistrer de nouvelles références dans la BDD hébergée
- à partir des boutons de création de fiches, je peux générer mes fiches directement

Oui cela semble relativement simple comme solution.

Word peut lui aussi directement pomper ses donner à travers un lien ODBC. Donc si vous choisissez d'abandonner Access et ses formulaires, au profit d'une nouvelle application, vous devriez toujours être en mesure de faire des fusions Word à partir de la nouvelle base de données.

Piste à creuser, peut être, à voir effectivement

Dans tous les cas, vous aurez besoin de vous faire aider par des personnes qui maîtrisent le sujet : la plupart des prestataires informatique n'ont pas la moindre idée de ce dont je suis en train de vous parler, et moi-même je sais que ça existe, sans être certain de la marche à suivre pour le faire tomber en marche.

Oui c'est clair, le seul bémol est de savoir comment trouver la personne pouvant le faire. Il faudrait que je vérifie sur ce site s'il y a une rubrique pour trouver des prestataires.

Merci pour ces réponses, cdlt.

[StringBuilder]

Après un test rapide, il semblerait que les données liées directement dans Access soit une fausse bonne idée.

En effet, autant Access n'a pas de souci pour travailler avec des formulaires dessus, autant lorsque je fais une fusion de publipostage dans Word, je ne retrouve pas ma table liée.

En même temps, je ne suis sûr de rien, car la fenêtre en question me semble bien étrange, et je ne suis pas certain de bien m'y prendre (le publipostage word, c'est un truc qu'on voit quand on fais des études de secrétariat, pas de programmation... c'est con mais c'est comme ça )

[SQLpro]

Un combinaison d'accès et de TSE me paraitrait plus simple à gérer dans ce cas de figure.
Bref, offrez vous un petit serveur à 500 € (Serveur HPE ProLiant ML10 Gen9 par exemple) dans votre infrastructure d'entreprise actuelle sur votre réseau, installez Accès et Word et votre base et lancez les services TSE de Windows.
Ouvrez les ports nécessaire pour utiliser TSE en distant.
Générez vos document de manière distante avec possibilité de récupérer le résultat de fusion en local.

C'est ce qui sera le plus simple à mettre en œuvre et le moins couteux !

A +