|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Futur Membre du Club
![]() Inscription : octobre 2007 Messages : 46 ![]() |
Bonjour,
A partir de deux bases de données Access, je souhaite n'en faire plus qu'une. Les données de l'une et l'autre sont assez similaires. Ces bases continueront de fonctionner, étant alimentées par des collègues. Mon objectif est d'avoir une base unique qui centralise les données et me permette de les retraiter. A l'intérieur des bases initiales, j'ai trois types de tables : Ma base sera mise à jour de manière hebdomadaire... et les importations seront automatisés (je les commanderais à partir d'un boutons de commande et un peu de code )il est fort probable également que ma base évolue vers un fractionnement frontale/dorsale, qui puissent permettre à mes collègues de consulter mes données retraitées. Le retraitement consiste en partie à réorganiser les données dans des nouvelles tables et à modifier automatiquement certaines valeurs... Là encore quelques requêtes mise à jour et ajout permettent de distribuer les données dans mes tables. Voici mes questions :
Pour l'instant je travaille de la manière suivante : Cela me semble long, peu optimisé et ce qui me fait peur c'est la taille de ma base sije ne compacte pas. Merci de vos éclairages. Xorbane. |
|
|
00
|
|
|
#2 |
|
Membre Expert
![]() |
Bonjour !
Quelle est la raison d'exister de deux base contenant les données ? N'est-il pas possible de "centraliser" tout cela ? P.S. A mon humble avis, il n'y a pas à attendre pour réaliser tes Frontales/Dorsales. |
|
|
00
|
|
|
#3 |
|
Futur Membre du Club
![]() Inscription : octobre 2007 Messages : 46 ![]() |
Bonjour,
Là où je travaille, nous travaillons parfois à l'ancienne et quand vraiment les tableaux excel ne suffisent plus... On trouve une solution comme on peut... Et comme les solutions sont trouvées par nos secrétaires qui contrôlent les données, remplissent les bases, font les extractions.... On utilise Access comme un super tableur... Donc deux fichiers Excel impliquent deux bases Access... Et pas questions de modifier quoi que ce soit. Moi et mes collègues qui consultons ces bases pour avoir des infos, n'avons accès qu'à une copie des bases... Hors de question que nous rentrions la moindre donnée... C'est pourquoi, Je souhaite introduire un nouveau système pour moi d'abord et mes collègues (non secrétaire) avec une base unique (qui nous évitera d'ouvrir une base pour savoir qu'en fait les données étaient dans l'autre). Seulement, il ne faut pas toucher au système mis en place (peut-être qu'avec le temps, les choses évolueront). C'est pourquoi, je souhaite créer une base qui ira régulièrement chercher les informations dans les bases initiales puis une fois rapatriées ou dans le transfert je classerais ces informations dans mes tables (ce que j'appelle le retraitement) de manière à ne pas avoir trois fois la même information et pouvoir faire mes propres requêtes, optimiser les formulaires de consultations et surtout introduire mes propres champs en complément des saisies du secrétariat... (l'idée c'est aussi d'avoir à mon service une base "dynamique" est pas le reflet de ce que j'aurais pu faire la semaine dernière) J'ai réfléchi à la structure de la base en terme de tables, champs, relation, le forum et la FAQ m'ont bien aidé. Mais je suis complétement à sec sur le meilleur moyen d'importer des données d'une base dans une autre... Au total une trentaine de table (2*16) des tables qui vont de 5 champs, 20 enregistrements : les tables de gestion dont il faut juste que je vérifie qu'elle n'ont pas changé et des tables de données dont la plus grosse fait 18000 enregistrements sur 90 champs. En général, les tables tournent autour de 2000 à 3000 enregistrements et une vingtaine de champs. J'ai réussi à intégrer du code qui me permet d'aller chercher les bases sur le réseau (merci les tuto dvp) et j'ai commencé à utiliser docmd.tranferdatabase ce qui fait que j'importe la totalité des tables initiales, je retraite les données dans mes propres tables (requête mise à jour puis ajout des nouveaux enregistrements en évitant les redondances de données) puis j'efface les tables importées et je compacte... Ca fonctionne pas si mal. mais il y a peut-être mieux ? Quand au problème frontal/dorsal ce n'est qu'une idée mais à la lecture des tuto cela me semble mieux que notre système actuel : les deux bases sont stockées sur un disque dur du réseau (un répertoire partagé sur un ordi qui fait office de serveur) et chacun ouvre les bases quand il en a besoin. L'idée est bien que chacun puisse acceder aux données sans souci. Désolé pour la littérature c'est peut-être un peu long mais j'espère avoir répondu à tes interrogations. Si tu me répond que la méthode que j'utilise est pas si mal et qu'il me suffira en final d'utiliser le fractionnement pour créer les dorsale/frontale... Cela me conviendra très bien. J'ai tenté aussi par la voie des recordsets mais cela m'est plus laborieux. |
|
|
00
|
|
|
#4 |
![]() ![]() René MAROTInscription : octobre 2005 Messages : 5 482 ![]() |
La seule amélioration que je vois, à part le Frontal/Dosral, serait de remplacer les docmd.tranferdatabase par des tables liées directement sur tes bases de prod.
Au lieu de faire une imporation des données initiales, tu fais un lien vers les tables qui sont donc toujours à date. Puis tu reprends ton traitement de fusion à partir de ces tables liées. Attention avec des tables liées, tu es directement sur tes données de prod et tu peux les modifier. On ne peut pas faire de lien en lecture seule que je sache. A+
__________________
Vous voulez une réponse rapide et efficace à vos questions téchniques ? Ne les posez pas en message privé mais dans le forum, vous bénéficiez ainsi de la compétence et de la disponibilité de tous les contributeurs. |
|
|
00
|
|
|
#5 |
|
Futur Membre du Club
![]() Inscription : octobre 2007 Messages : 46 ![]() |
Salut Marot_r,
Je vais continuer avec docmd.tranferdatabase puisque j'ai commencé et ainsi pas de soucis les bases restent indépendantes. Merci pour l'échange. Xorbane |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com