Architecture client/serveur problème mise à jour du serveur

Bonjour à tous ,
J'ai une base access qui est divisée en deux avec les tables sur un serveur et les base frontoffice sur chaque poste.
Pour mettre à jour les tables je me sert d'extraction issue d'un erp, et dans le formulaire de mon frontoffice J ai un bouton avec une macro qui supprime les tables de la base qui est sur le serveur puis exécuté un import enregistré de mes extractions Excel.
Sauf que au lieu de mettre à jour les tables qui sont sur le serveur ca me remporte les tables dans la base du frontoffice de l'utilisateur qui fait la mise à jour.....

Comment faire pour que ce soit la base du serveur qui se mette à jour????
Merci de votre aide!

Bonjour,

ben, il faut mettre à jour le code...:mrgreen:

Certes mais comment????y a pas moyen sans codage en passant par access?

Je pensais qu'en séparant les tables du reste access arriverait de lui même à savoir ou mettre à jour....

est ce que la solution pour moi consisterait a cocher la case "toujours demander un nouvel emplacement" dans le gestionnaire de table liées ?

bonjour,

il semble que le bouton et la macro dont tu parles doivent être utilisées à partir du serveur, permettant de charger tes excel

ensuite les tables liées entre client et serveur, c'est à faire une fois et c'est tout

Effectivement, manipuler des objets d'une base distante, c'est plutôt un job pour VBA. Les macros doivent savoir manipuler les objets de la frontale, mais une table liée, ce n'est qu'une fenêtre sur le serveur, tu ne peux même pas ajouter une colonne en passant par une table liée. C'est pourquoi Accessisgood te suggère de gérer cette fonction de mise à jour sur la base dorsale.

Pour se limiter aux macros et travailler à partir de la base frontale, la seule solution que je vois consiste à importer les données Excel en local (change le nom des tables), puis mettre à jour les tables liées avec des requêtes (de suppression pour tout vider - dans le bon ordre pour respecter l'intégrité référentielle - , puis d'ajout pour déverser les données locales sur le serveur - encore une fois, dans le bon ordre - donc l'ordre inverse de la suppression...).
Ce qui va alourdir ta base frontale; il faudra donc penser à supprimer les données locales et à compacter (il existe une option pour compacter à la fermeture).

Cordialement,
Paraffine.

Bonjour,
est ce que ce que suggère Accessisgood (gérer cette fonction de mise à jour sur la base dorsale) est réalisable au travers d'un bouton dans la base frontale, l'idée pour mes utilisateurs étant de n'avoir que la base frontale !

Citation:

---

Envoyé par slickfast

est ce que ce que suggère Accessisgood (gérer cette fonction de mise à jour sur la base dorsale) est réalisable au travers d'un bouton dans la base frontale, l'idée pour mes utilisateurs étant de n'avoir que la base frontale !

---

Sans doute, mais avec VBA !

D'après moi tes choix sont donc;
- manipuler les tables de la base dorsale en direct, avec une macro (Si tu ne fais pas la manœuvre toi-même, cela implique de fournir un accès direct à au moins un utilisateur - pas franchement recommandé, selon moi -)
- manipuler les tables de la base dorsale à partir des bases frontales (avec VBA)
- manipuler les données depuis la base frontale, en passant par un import local que tu déverses par requêtes (cf. mon précédent message).

EDIT : à la réflexion, je ne vois pas pourquoi tu ne peux pas déverser directement dans les tables liées ! Il faut simplement faire une requête de suppression des données au préalable, pour vider les tables, puis importer depuis Excel en ajoutant les données (dans ma version d'Access, c'est l'option "Ajouter une copie des enregistrements a la table : [T_trucmuche]". Il faut simplement ne pas supprimer les tables liées, tu te retrouverais le bec dans l'eau, car l'import ne peut pas les reconstituer; il ne sait que créer une table locale en l'absence de structure d'accueil ad hoc. La seule difficulté, si tu as des relations d'intégrité dans la base dorsale, est de gérer correctement l'ordre des suppressions et des imports.

Cordialement,
Paraffine.

Bon, je penses qu'aux final je vais laisser les tables en local sur chaque poste....

Aucun besoin de partager les données? Si du point de vue métier on veut du "chacun dans son coin", alors c'est effectivement plus simple.
Y a t-il beaucoup de tables en jeu? Volumineuses ? des relations compliquées?

Cordialement,
Paraffine.

Bonjour
Finalement J ai trouvé la solution via une requête en création de table et la je peux créer la table dans la.base du serveur!

Merci de vos réponses en tous cas!!