Base ACCESS 2010 fractionnée et liaison UNC
blux Messages postés 5007 Date d'inscription Statut Modérateur Dernière intervention -
Le problème des bases ACCESS 2010 fractionnées à installer sur un poste « Client » après les avoir verrouillées (par conversion des bases accdb en accde) est de pouvoir conserver les liaisons sur n'importe quel poste entre la base frontale et la base dorsale.
Pour cela, il semble qu'il faille utiliser des liaisons réelles du type UNC et non celles définies avec un lecteur mappé comme H:\, F:\,.....
Est-ce quelqu'un connait la syntaxe à utiliser?
Un grand merci pour votre aide
- Base ACCESS 2010 fractionnée et liaison UNC
- Base de registre windows - Guide
- Access appdata - Guide
- Liaison torride ✓ - Forum Vos droits sur internet
- Gigaset a170h problème base ✓ - Forum telephonie fixe
- Arnaque rdv torride ✓ - Forum Consommation & Internet
60 réponses
- 1
- 2
- 3
Le problème porte sur la préservation des liaisons entre la base frontale et la dorsale dans une Access 2010 fractionnée après verrouillage en accde, en privilégiant des liaisons UNC plutôt que des lecteurs mappés. La solution recommandée consiste à créer une table dans la frontale ne contenant qu'un champ, un booléen, qui passe de 0 à 1 après le premier démarrage pour lancer puis maintenir la liaison des dorsales. En cas de modification des chemins, il faut répondre à des questions sur les répertoires et la persistance des liens, c'est-à-dire savoir si les tables liées continueront à pointer vers les mêmes dorsales. D'autres échanges évoquent l'utilisation possible de DAO 3.x et d'une bibliothèque adaptée pour couvrir les besoins de gestion des liaisons dans un contexte accde sur postes variés.
Vos PC sont en reseau. En ouvrant l'explorer, vous allez jusqu'a ouvrir le repertoire ou est votre base sur votre server. Vous aurez le chemin dans la barre adresse de l'explorer.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre questionL'installation des bases sur les postes "client" se fait après verrouillage (par conversion des bases accdb en accde), ce qui veut dire qu'après je n'ai plus accès à l'explorer.
Ce que je cherche à faire, c' est établir les liaisons entre la base frontale et la base dorsale avant la conversion (sachant que la base dorsale se trouve dans un sous-répertoire de la frontale), et que ces liaisons fonctionnent sur n'importe quel poste "client".
Nous aurons dans ce cas une liaison définie avec un lecteur mappé comme h:\ ,F:\... et non une liaison du type UNC si je ne me trompe....
Non, dans la barre d'adresse vous avez: \\\server\repertoire de partage\sous-repertoire......
Je n'ai pas de PCs en reseau pour l'instant, donc je ne peut pas faire de simul. La semaine prochaine j'essaierai si vous n'avez pas resolu votre probleme.
Un grand merci par avance.
Bon WE
tu peux regarder ce qui a été fait ici :
https://forums.commentcamarche.net/forum/affich-14845990-access-gerer-plusieurs-bases-avec-1-menu-gen
Ca devrait aller dans le sens que tu souhaites...
Je ne vais pas avoir le temps de creuser ce matin, mais je regarde de plus prêt dès que possible.
A + en encore merci pour ton aide
J'ai posté le fichier chez free :
http://dl.free.fr/getfile.pl?file=/McQsO40z
Mise à part un petit problème de compilation, je reste baba devant ce développement! Mes connaissances en VBA sont cependant trop limitées pour pouvoir appréhender tous ces enchaînements (je n'arrive même pas à voir comment le module est rattaché au formulaire "Menu" : dans la feuille des propriétés, je ne vois rien...).
De mon côté, j'ai compris que j'étais sur une fausse piste avec ma liaison UNC : j'espérais par le biais d'une formulation type pouvoir accéder automatiquement à une base dorsal située dans un sous-répertoire de la base frontale (ou ailleurs), mais apparemment, c'est beaucoup plus complexe et là, je me sens un peu démunie...
Le code est rattaché à l'objet "zone de liste" du formulaire menu, c'est pour cela que tu ne vois rien...
Sinon, tu es bien dans la bonne direction.
Tu as deux solutions pour régler ton problème :
- tu codes en dur les liens entre chaque table et la base dorsale
- tu crées une table non liée avec la dorsale, qui va contenir le chemin unc de la base dorsale, et à chaque ouverture de ton accde, tu vas remapper les liens entre l'accde et la dorsale.
Je peux t'aider à le faire, si tu le souhaites...
Entre les 2 solutions, je ne sais pas qu'elle est la plus adaptée sachant qu'au départ, je n'ai aucune connaissance de l'arborescence chez le "client"...
Quels sont les avantages et inconvénients des 2 méthodes?
Dans ce cas, il faut créer l'accde chez le client quand on connait son arborescence.
Je privilégie cependant le deuxième solution, qui a l'avantage de ne pas obliger à modifier le code à chaque changement de chemin.
Mais on peut aussi prévoir un truc qui va ouvrir une boite de dialogue dans laquelle on choisit la base visée, comme ça le fichier accde peut être créé où on veut. Mais il faut avoir confiance en l'utilisateur pour ne pas qu'il s'amuse à changer les chemins toutes les 5 minutes...
Petites précisions avant de démarrer :
- le poste sur lequel je travaille n'est pas en réseau
- il pourra y avoir éventuellement 2 ou 3 bases dorsales
Est-ce que ça pose problème?
Il s'agit d'un applicatif multi-utilisateurs que j'ai développé qui se compose :
- d'une base frontale
- d'une base dorsale contenant des données à mettre à jour via la frontale
- de 2 autres bases dorsales non installées dans le même répertoire que la précédente : à partir de tables liées, je lance une requête qui va alimenter pour la 1ère et complémenter pour la seconde une table dans la 1ère base dorsale qui va permettre de faire des contrôles de cohérence. Cette phase peut être soit maintenue soit modifiée dans sa conception en fonction des clients. C'est pour ça que je te parlais d'une ou plusieurs bases dorsales
- un formulaire "MENU" s'ouvre automatiquement à l'ouverture de la base frontale via une macro autoexec. Ce formulaire est adossé à une table qui se trouve dans la base dorsale (si besoin est, il est possible de l'adosser à une table du frontal).
Ensuite, il faudra connaitre/établir la règle pour les tables liées : est-ce qu'elles pointeront toujours vers les même dorsales (en parlant du nom), mais que les répertoire pourront être différents ?
- la 1ère base dorsale aura toujours le même nom
- les 2 autres (ou l'autre s'il n'y en a qu'une autre) peuvent être issues de n'importe quelles bases et se trouver n'importe où : encore une fois je pense qu'il m'est tout à fait possible de traiter le problème différemment, afin de ne plus avoir ces 2 autres dorsales.
Tu peux prendre ce que tu veux pour la table et le champ.
Pour le choix des différentes dorsales, il va falloir une règle de gestion pour chaque table puisqu'elle pourra, selon ce que tu me dis, être liée à une dorsale particulière. Qui décide cette répartition ?
- Nom de la table : TblLiaisonDorsale
- Nom du champ OUI/NON : Liaison
Pour les dorsales, après réflexion, je simplifie : je n'en conserve qu'une et je traiterais l'aspect contrôle différemment.
- 1
- 2
- 3