Discussion :

[tiferg]

Bonjour à tous,

Voilà, je cherche à utiliser access comme SQL Serveur (Cela peu peut-être paraître prétentieux). Je souhaite utiliser un appli.accdr sur les postes client qui appellent des procédures ou fonctions stockées dans le fichier contenant les tables Data.accdr par exemple.

Ma 1ere question : Cela est-il pertinent ? à savoir est-ce que cela optimisera les traitements. Les ressources utilisées seront-elles celles du serveur dans ces circonstances ?

Ma seconde question : Afin d'executer les procédures stockées avec passage de paramètres, dois-je utiliser ADODB, DAO, ou des appel grace à ce genre de syntaxe : Set acApp = New Access.Application

Merci pour vos conseils

Cordialement

[LedZeppII]

Bonsoir,

Access n'est pas client/serveur. C'est un système de base de données type fichier.
La base de données peut être mise en partage réseau sur un serveur de fichiers.
Ca ne va pas plus loin que ça.
Voir réponse de Loufab dans un autre post.

Access n'est pas un logiciel serveur comme SQL Serveur, Oracle, MySQL, ...

Donc les ressources mises en oeuvres seront essentiellement celles de la station de travail.

En revanche, Access peut être utilisé en tant que client de SQL Serveur (projets adp).

A+

[bruce-willis]

Bonjour,
Access n'est pas du tout client/serveur, alors comment faire ? Migrer vers SQL Server ?
Je croyais que l'image d'une base de données est un tiroir rempli de chemises avec des tables et feuilles dedans où tout le monde y accède (serveur), Access n'est donc pas comme ça !!

Si on crée alors une source de données ODBC pour le fichier .MDB sur un PC qu'on va considérer comme serveur et mes programmes sont sur d'autres programmes qui vont se connecter sur cette source, il y a donc risque de saturation de la machine par rapport à un BD SQL Server ou ORACLE ??

[LedZeppII]

Bonsoir,

J'ai touvé ce lien Migration d'une base de données d'Access 2002 vers SQL Server sur msdn.
Aller à Achitecture (lien en début de page) où Access et SQL sont comparés.
Notament voir plus bas Modèles d'accès aux données (env. 3 x PgSuiv).
Tout est expliqué mieux que je ne saurai le faire.

Bonne lecture.

[cbleas]

Bonsoir,
Pourquoi vous prendre la tete pour faire ce que SQL server 2005 fait parfaitement avec ACCESS.
Vous avez avec ACCESS un outil vraiment bien pour faire une application et SQL server le moteur qui je pense permettra de tirer le meilleur parti de votre application et cela aussi facilement qu'avec une base de donnée ACCESS.

Bon courage

[tiferg]

Merci à tous pour votre réponse, j'ai en effet télécharger SQL 2005 et installé puis convertie ma base mdb. Je n'ai plus qu'à modifier quelques partie de code dans mon appli access cliente dans laquelle les option dbopendynaset ne sont plus adaptées et où mes commandes currentdb.execute("") doivent-être rebasculées en currentdb.execute "",dbseechanges

Cordialement

[le.dams]

Bonjour à tous,

Je vais peut être avoir l'air d'un noob mais je voudrais commenter une des réponses :
"Donc les ressources mises en oeuvres seront essentiellement celles de la station de travail."
Pour ma part (Access), soit je mets la frontale et la dorsale sur le serveur (+ raccourcis de lancement sur le poste client) et c'est le serveur qui fait tout le travail pour la poste client (et transfert via le réseau = un peu lent de temps en temps)... soit je mets la frontale sur le poste client et la dorsale sur le serveur et là les temps d'accès sont très courts.

J'ai une base d'un 10N de table et la plus graosse fait 63 000 ligne sur 24champs, certains de mes formualires appellent plusieurs tables à la fois et nous sommes 25 poste clients en accès sur la base dorsale... aucun problème à ce jour !

[vodiem]

salut à tous,

le.dams> oui, mais quand tu auras à passer par un réseau vpn avec une connexion adsl tu comprendras la douleur.

j'ai eu ce cas et j'ai hésité à basculer sur sql serveur pour différentes raison propre à ma situation.
pour éviter cela, j'ai simplement exporter les données lors de maj de celle-ci et de l'autre côté intégré le fichier export lors de sa présence.
c'est simple quand il s'agit de faire cela que dans un sens, mais cela deviens un casse tête s'il faut réintégrer les données modifiées, auquel cas mieux vaut passer par un vrai client/serveur.

[marot_r]

Pour ma part (Access), soit je mets la frontale et la dorsale sur le serveur (+ raccourcis de lancement sur le poste client) et c'est le serveur qui fait tout le travail pour la poste client (et transfert via le réseau = un peu lent de temps en temps)...

Hum, là j'ai des doutes, Access s'exécute toujours sur la machine locale quelque soit l'emplacement de la base frontale, non ?

Donc la station qui fait vraiment rouler l'appli c'est celle de l'utilisateur, le serveur se contente de livrer les morceaux nécessaires et les données, n'est-ce pas ?

A+

[mout1234]

Bonsoir,

Hum, là j'ai des doutes, Access s'exécute toujours sur la machine locale quelque soit l'emplacement de la base frontale, non ?

Donc la station qui fait vraiment rouler l'appli c'est celle de l'utilisateur, le serveur se contente de livrer les morceaux nécessaires et les données, n'est-ce pas ?

A+

Tout à fait d'accord avec marot_r, que tu places les deux parties sur le serveur ou le frontal en local, le serveur ne joue qu'un rôle de serveur de fichier et aucun service ne tourne sur ce dernier, hormis la gestion de l'accès aux fichiers.



A l'opposé, quand on utilises SQL Server ou équivalent, il y a une application qui tourne sur le serveur, offrant ses services aux frontaux.

[marot_r]

A l'opposé, quand on utilises SQL Server ou équivalent, il y a une application qui tourne sur le serveur, offrant ses services aux frontaux.

et ça fait toute une différence. J'ai une appli Access/Oracle et quand c'est Oracle qui roule les requêtes c'est nettement nettement plus rapide.

A+

[vodiem]

salut,
dans ce que je comprends de ce que dit le.dams, le frontale étant sur le serveur, le poste client charge le fichier frontale avant son ouverture ce qui rends le lancement effectivement plus lent.
le chargement du fichier frontal dans la mémoire du poste client ne se fait pas intégralement, lors d'ouverture d'un form par exemple, access construit dynamiquement le form en mémoire et va donc le construire à partir du fichier à son origine (n'existant pas sur le poste client) il demande le fichier sur le poste serveur ce qui ralenti effectivement le traitement.
si le frontal est sur le poste client, seul les données sont véhiculées ce qui rends le traitement "moins lent".

enfin, j'ai eu à faire les deux cas de figure, je n'ai pas eu alors de pb de temps mais cela me parait logique, bien que je ne peux être garant sur le mécanisme de gestion d'access.

[le.dams]

Bonjour à tous,

Effectivemement Vodiem, c'est tout à fait cohérant et colle parfaitement avec ce que j'observe.
Par rapprot à l'appli en VPN, j'ai opté par une solution via une service TSE et du coup ça fonctionne bien... mais bon le TSE a aussi ces défauts.

a+