Discussion :

[katcz]

hello,

Je cherche une solution pour avoir une BD qui tourne sur un serveur distant, et qui serait accessible directement depuis Excel côté client dont voici quelques specs:

• BD access voir MSDE ou si vous avez des suggestions...
• BD petite: 10Mo max
• 5 à 10 connexions simultanées
• client sous Excel

En local, j'ai réussi à faire communiquer Excel et Access via DAO mais, je n'ai pas réussi à savoir si DAO permettait l'accès à une base de données sur un serveur distant.

--> je me demandais donc s'il est possible d'avoir un client excel et serveur access qui communique via DAO?
--> et si oui, est ce que cette solution est performante ou est qu'il vaut mieux envisager autre chose (la seule contrainte est d'avoir excel en local)?

merci d'avance

[motrin]

Je sais qu'il est possible de faire un programme Access avec DAO si ta bases de données est en réseau (je l'ai déjà fait). Je ne verrais pas pour quelle raison tu ne pourrais pas le faire avec Excel (avec excel je n'ai jamais utilisé de BD). La connexion à la bases de données réseau si je me souviens bien se fait en 2 lignes très simple.

bonne chance

[=JBO=]

Bonjour,

Voilà un peu comment je vois les différentes couches logicielles qu'implique une application (Access, Excel, VB6....) qui exploite une base de données MDB.


Access... Server Or Not Server ? That is the question.
Access n'est pas un serveur de bases de données.
Access est un serveur COM qui peut être contrôlé via l'Automation.

Dans le cas d'une BD dans un fichier MDB, exécuter une instance d'Access sur un PC implique :
(1) sur le même PC:
* une couche logicielle d'accès aux données chargée en mémoire,
* une instance du moteur de base de données JET
(2) sur le même PC ou sur un autre PC du réseau local:
* un fichier MDB accessible à travers le système de fichiers.

Par conséquent, dans une telle configuration, le seul serveur serait un serveur de fichiers.

Question:
Quand tu demandes si <<Excel peut être un client d'un serveur Access via DAO>>, ça n'a pas de sens.

Explication:
Access ET Excel sont tout deux des clients d'un serveur de fichiers.
Ils utilisent DAO/JET pour lire et écrire dans des fichiers MDB "partagés".
DAO/JET n'est qu'un moyen de communication INDIRECTE.

Client Excel / Serveur Access ==> Automation:
L'utilisation de l'Automation permettrait à un client Excel de PILOTER un serveur Access.
Dans ce cas, la relation entre les 2 applications se base sur COM (Common Object Model). Cette technologie intégrée dans Windows permet même à un Client d'accéder à un Serveur situé sur un autre PC (cf. Distributed COM).

P.S. Je réponds à ta question dans un prochain post...

[=JBO=]

Suite...

Avec Excel, il est assez aisé d'insérer dans une feuille des données provenant d'une source de données (DAO, ADO, ODBC, fichier texte...).

Utiliser un QueryTable ?
Avec l'objet de programmation QueryTable, Excel offre un moyen puissant pour exécuter des requêtes à la demande ou en automatique.

Un assistant intégré d'Excel permet de créer des objets QueryTable très simplement:
Données >> Données externes >> Créer une requête...
Ensuite tu peux actualiser les données dans Excel, via le menu [Données] ou la barre d'outils [Données externes].
Les QueryTables créées de cette façon permettent d'importer des données issues d'une source de données ODBC, fichier texte ou tableau d'une page Web.

Mais tu peux aussi programmer toi même cet objet QueryTable (par exemple lui assigner directement un Recordset DAO ou ADO).
Tu peux aussi programmer "à la main" le remplissage des cellules.

A lire absolument ! Le tutoriel de Cafeine sur la communication entre Excel et Access (http://cafeine.developpez.com/access/tutoriel/excel/).

Actualiser les données ? Excel ==> MDB
Maintenant, pour mettre à jour les données du fichier MDB à partir du classeur Excel, il n'y a rien d'automatique: là il te faudra nécessairement programmer.
Mais si ton objet QueryTable est basé sur un Recordset DAO ou ADO, alors tu peux utiliser ce Recordset pour réaliser les mises à jour .

Pour résumer:
* Tu peux utiliser le couple DAO/JET pour stocker des données dans un fichier MDB.
* Tu peux connecter un recordset DAO dans une feuille Excel via l'objet QueryTable (tu peux aussi copier les données dans les cellules "à la main").
* Tu peux modifier les données du fichier MDB, via des requêtes SQL, ou directement à travers le Recordset.
* Si ta BD est bien construite, alors cette solution est performante, économique et assez simple à mettre en oeuvre, que les données soient locales ou sur un serveur de fichiers.
* JET ne permet pas un accès à des fichiers en dehors du réseau local.
* Ici, Access n'intervient pas directement.

[katcz]

ok merci!

Je n'avais effectivement pas très bien formulé mon problème puisqu'access n'intervient pas directement, les fichiers mdb étants directements manipulés depuis excel.
Merci aussi pour le lien vers le tuto, j'étais déjà tombé dessus mais sans m'y attarder vraiment (en fait j'étais asssez rapidement passé au tuto DAO... )

accès serveur DB:
par contre tu me dis que Jet ne permet pas l'accès à des fichiers en dehors du réseau local... ok mais concrètement, comment faire pour y accéder sur le réseau local et pour gérer des accès concurrents?
- créer une source de données ODBC pour chaque client? peu pratique non?
- créer un fichier mdb client lié à la base JET centrale? est ce que ce n'est pas trop lent?
- utiliser MSDE plutot que Access? mais est ce vraiment plus simple dans la mesure ou je n'ai pas bcp de données à gérer (10Mo) et seulement 5-10 users...

Au vu de ce que j'ai pu lire sur le sujet, je ne sais pas laquelle de ces trois solutions choisir. Donc si quelqu'un à des suggestions...

Edit:
je viens de tomber par hasard sur un comparatif entre Jet et SQL server qui ferait plutot pencher la balance du côté de Jet... puisque Jet parait largement suffisant pour gérer 5-10 users...
le comparatif: Jet vs SQL server


Edit (c'est tout bon cette fois!!)
après quelques jours de recherche... j'ai enfin trouvé ma solution!
En partie grâce à ce cours sur la sécurité Access, qui donne les avantages/inconvénients de chaque architecture access.
Et j'ai aussi retrouvé cet ptit comparatif entre ADO et DAO... DAO parait donc être la meilleure solution pour de l'Access!