Pilotage d'Excel multi-instances par Access multi-instances: Pb d'architecture?

Bonjour à tous,

Le titre est aussi abscons que l'idée que je me fais d'une solution pour mon problème qui est le suivant:

• Un dev. Access mis sur le réseau de l'entreprise avec appels multi-utilisateurs
• Depuis l'IHM, on sélectionne les critères de sélection, base de la constitution d'un jeu de données. Le jeu de données est constitué à la volée sur la base des items sélectionnés dans les objets graphiques. Pas de sauvegarde dans des tables
• Le jeu de données alimentent les indicateurs et des graphes d'un fichier Excel modèle

La question est la suivante, sachant :

• Qu'il y a plusieurs utilisateurs => multi-instances de l'outil Access appelé sur le réseau
• Qu'Access pilote un fichier Excel => ouverture de différentes instances Excel
• Qu'une fois l'instance d'Excel renseignée, elle n'est plus pilotée par Access. Access sert juste à alimenter l'instance Excel qui ensuite vit sa vie

Quelle architecture dois-je mettre en place pour une gestion multi-instances Excel depuis des instances multiples d'un outil Access

J'espère que cela parlera à quelqu'un car c'est vraiment et remercie toute aide par avance:f1:

Bonjour informer,

Si j'ai bien compris ta question, c'est très faisable.

Citation:

---

Un dev. Access mis sur le réseau de l'entreprise avec appels multi-utilisateurs

---

Principe base frontal/dorsal.

Citation:

---

Depuis l'IHM, on sélectionne les critères de sélection, base de la constitution d'un jeu de données. Le jeu de données est constitué à la volée sur la base des items sélectionnés dans les objets graphiques. Pas de sauvegarde dans des tables

---

Requête basée sur un formulaire de recherche multi-critères.

Citation:

---

Le jeu de données alimentent les indicateurs et des graphes d'un fichier Excel modèle

---

Un fichier Excel sur le réseau qui sert de template.

Citation:

---

Qu'il y a plusieurs utilisateurs => multi-instances de l'outil Access appelé sur le réseau

---

Avec le principe frontal/dorsal aucun problème.

Citation:

---

Qu'Access pilote un fichier Excel => ouverture de différentes instances Excel

---

Access ouvre le template injecte les données.

Citation:

---

Qu'une fois l'instance d'Excel renseignée, elle n'est plus pilotée par Access. Access sert juste à alimenter l'instance Excel qui ensuite vit sa vie

---

Access sauvegarde le fichier sous un autre nom à l'endroit désiré. Ainsi le fichier Excel est exploitable indépendamment d'Access.

Bonne journée

Bonjour Robert1957

Merci beaucoup pour ta réponse. J'avais entrevu la solution notamment après la lecture de l'excellent tuto de Dolphy35 http://dolphy35.developpez.com/artic.../basesreseaux/

J'en profite pour te poser enfin de compte les questions qui me taraudent :marteau::wow:

QUESTION 1
Chaque instance du frontal Access ouverte sur un poste a-t-il son propre environnement, c'est à dire est-il complètement indépendant des instances ouvertes sur les autres postes et les requêtes faites à la volées dans une instance ouverte sur un poste de travail ne viendront pas polluées les instances ouvertes sur les autres postes?

QUESTION 2

Un objet Excel créé comme suit, l'est-il seulement dans l'environnement du poste utilisateur ? Et n'y a-t-il aucun risque de blocage suite à des appels successifs du template par l'utilisateur selon des critères de sélection différents???

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Dim appExcel As Excel.Application Dim myWorkbook As Excel.Workbook Dim path As String   path = Me.frmCheminFicExcel!cheminFicExcel & "\" & Me.frmCheminFicExcel!fichier   Set appExcel = CreateObject("Excel.Application") Set myWorkbook = appExcel.Workbooks.Open(path) appExcel.Visible = True Set appExcel = Nothing Set myWorkbook = Nothing

---

QUESTION 3

Sachant qu'Excel est seulement en requête (SELECT), est-il plus pertinent d'avoir l'architecture suivante :

• Une base de données Access unique sur le réseau
• un template excel distribué sur les postes des utilisateurs qui se connecte à la base de données Access

Ou l'architecture:

• Une BDD Access unique sur le réseau
• Un frontal Access unique sur le réseau qui est chargé dans l'environnement du poste utilisateur => multi-utilisateurs
• Un template Excel unique sur le réseau appelé par le frontal depuis chaque instance du frontal Excel

QUESTION 4
Après la lecture de moult sites, il est recommandé d'utiliser DAO avec le moteur JET, es-tu d'accord avec cette préconisation?

QUESTION 5
Préconises-tu aussi de travailler avec un workspace ou DAO le fait de facto?

La toute dernière, pour la route:
Pourrais-tu me dire les avantages / inconvénients du workspace si cette question a un sens car DAO impose peut-être son utilisation. Le workspace ne permet-il pas aussi de créer une instance spécifique à chaque connection DAO => reboucle sur ma question d'environnement spécifique à chaque instance Access ouverte?

J'espère ne pas avoir abusé, pas partir dans tous les sens, te casser la tête :scarymov:!

Et encore merci pour ton aide précieuse :chin::pingoin2:

Bonjour informer,

Question 1 : Tout à fait indépendant.
Question 2 : Pas de problème si tu sauvegardes dès l'ouverture du fichier Excel. Ainsi comme spécifié dans ton premier post le fichier Excel vit sa propre vie...

Code:

---

appExcel.ActiveWorkbook.SaveAs "LeDossierDésiré"

---

Question 3 : Ta deuxième architecture me fait penser à des accès à distance (genre RDP)? Je crois qu'une dorsale sur le réseau, une frontale sur les postes utilisateurs et un template sur le réseau devrait bien fonctionner.
Question 4 : Je préfère fonctionner avec DAO mais je crois qu'il y a une question de gout dans cette réponse.
Question 5 : Si tu parles ici du .mdw cela n'existe plus avec les versions 2007 et 2010 d'Access.

Bonne journée

Robert1957:merci: pour le temps passé sur mon post.

Les questions 1, 2, 4 étant évacuées grâce à toi, je reviens sur la :

QUESTION 3

Tu préconises d'installer

1. La base de données unitaire Access sur le Réseau
2. Un frontal sur tous les postes clients.
3. Le template unitaire Excel sur le réseau

La frontale est pour toi indifféremment Access ou Excel avec un UserForme pour la sélection des critères?

Quels inconvénients verrais-tu à ne mettre qu'un frontal Access sur le réseau, appelé par tous les utilisateurs depuis leur poste?

1. Impossibilité d'ouvrir le frontal en nombre suffisant?
2. Lock sur des tables?
3. Impossibilité de modification du frontal si existe au moins une instance laissée ouverte ?
   Contournable en initialisant une procédure de déclockage de tous les utilisateur en tapant dans le .ldb?

QUESTION 4

Bon je ne sais pas ce qu'est un .mdw et n'étant plus d'actualité, ne chercherai pas en connaitre plus.

Je parle de la création d'un workspace lors d'une connexion DAO comme ecrit dans la page msdn https://msdn.microsoft.com/fr-fr/lib.../ff822782.aspx,

Code:

---

1 2 3 4 5 6 7

Dim wrk As DAO.Workspace Dim dbC As DAO.Database Dim dbX As DAO.Database   Set wrk = DBEngine(0) Set dbC = CurrentDb Set dbX = wrk.OpenDatabase("e:\books\acc2007vba\myDB.accdb")

---

ou on peut lire que

Citation:

---

Un espace de travail est un objet non persistant qui définit la manière dont votre application interagit avec les données à l'aide du moteur de base de données Microsoft Access. Utilisez l'objet Workspace pour gérer la session active ou pour démarrer une session supplémentaire. Dans une session, vous pouvez ouvrir plusieurs bases de données ou connexions et gérer des transactions. Par exemple, vous pouvez :

• Utilisez les propriétés Name, UserNameet Type pour établir une session nommée. La session crée une étendue dans laquelle vous pouvez ouvrir plusieurs bases de données et exécuter une instance de transactions imbriquées.
• Utilisez la méthode Close pour fermer une session.
• Utilisez la méthode OpenDatabase pour ouvrir une ou plusieurs bases de données existantes dans un espace de travail.
• Utilisez les méthodes BeginTrans, CommitTranset Rollback pour gérer des transactions imbriquées dans un espace de travail de traitement et utiliser plusieurs objets Workspace pour organiser des transactions multiples, simultanées et se chevauchant.

---

J'en retiens surtout la possibilité de taper dans plusieurs bases de données Access en simultanée avec possibilité de faire des traitements en parallèle sur des recordsets alimentés par différentes bases.

QUESTION ULTIME, ben non
Pour pouvoir exploiter plusieurs BDD sources en simultanée, faut-il OBLIGATOIREMENT utiliser un workspace?

QUESTION ULTIME, ben oui a priori
Peux-tu me dire comment utiliser Codedb car j'ai lu dans le tuto de Christophe WARIN http://warin.developpez.com/access/dao/?page=partie_3 que

Citation:

---

Contrairement à la méthode CurrentDb qui renvoie la base de données active, cette méthode retourne un objet Database correspondant à la base de données qui contient le code en cours d'exécution .
CodeDb est à utiliser lors de la création de compléments ou de base de données bibliothèques. En effet la base Add-in ne sera pas la base active. La méthode CurrentDb ne retournera donc pas le bon objet Database. Tout comme CurrentDb, Codedb retourne une nouvelle instance de l'objet Database. Vous devez donc récupérer son résultat dans un objet Database pour pouvoir l'exploiter.

---

Encore merci pour ton aide :applo::pingoin2:

Bonjour informer,

Question 3 :

Citation:

---

Tu préconises d'installer
La base de données unitaire Access sur le Réseau
Un frontal sur tous les postes clients.
Le template unitaire Excel sur le réseau

---

Oui

Citation:

---

La frontale est pour toi indifféremment Access ou Excel avec un UserForme pour la sélection des critères?

---

De par mes connaissances je préfère et de beaucoup un formulaire Access.

Citation:

---

Quels inconvénients verrais-tu à ne mettre qu'un frontal Access sur le réseau, appelé par tous les utilisateurs depuis leur poste?

---

1. Impossibilité d'ouvrir le frontal en nombre suffisant? Environ 10
2. Lock sur des tables? Pas de différence
3. Impossibilité de modification du frontal si existe au moins une instance laissée ouverte ? Si tu travailles avec Windows server version assez récente il est possible de "Killer" le ldb, pour les autres je ne connais pas
   Contournable en initialisant une procédure de déclockage de tous les utilisateur en tapant dans le .ldb? Pas facile

Il est recommandé d'utiliser frontal/dorsal et ce pour plusieurs raisons. Ce qui est différent dans ton approche est une ou plusieurs frontales. Mon expérience me dit que plusieurs frontales c'est mieux.

Question 4 : Ok là je comprend la question. Tu n'as pas besoin d'un second workspace. Dès que tu ouvres Access il est déjà créé.

Question ultime, ben non : La réponse est aussi non.

QUESTION ULTIME, ben oui a priori : Pourquoi voudrais-tu aller chercher du code dans une autre application? Si c'est juste pour lire des tables provenant de différentes bases, ce n'est pas nécessaire.

Bonne journée

Encore un grand :merci: Robert1957 pour tous tes conseils que je vais m'empresser d'appliquer

Maintenant, j'ai plus qu'à...:ptdr:

A bientôt peut-être, voire surement, pour de nouveaux posts!:mouarf: