Discussion :

[BigFoot69]

Bonjour à tous !

J'ai un petit cas à vous soumettre :

J'ai une base de donnée Access de petite taille (~40Mo) situé sur server de dépot de fichier (share).
Je veux donner un accès à cette base via l'intranet uniquement pour de la consultation (donc uniquement des SELECT). La base sera consultée par environ 35-40 personnes via le web, et sera modifiée par 3 personnes via Access.
Cependant lors de l'accès simultanée à la base via Access (je n'ai pas testé via le web), ça rame complètement !!
Je me demande donc si je dois migrer de Access vers un autre système.
Cela m'amène à me poser les questions suivantes:

1. Combien de connexions simultanées peut gérer Access (comprenez: sans ralentissement excessif)
1.a. en ouvrant directement le fichier .mdb (d'après mon test perso, même pas 2 )?
1.b. en connexion web via php/odbc ?

2. Est-il possible d'utiliser Access en frontend avec une autre base (ex:MySQL) ? J'entends par là, avoir une interface sur Access qui utilise des données sur une base MySQL (ou autre).

3. Si je dois tout migrer, vers quoi dois-je m'orienter (MySQL, PostGreSQL, SQL server, Oracle...) ? (simplicité de migration, portabilité des requêtes...)

Je suis un peu paumé pour l'instant entre 3 choix:
- garder la base actuelle en croisant les doigts pour que les access web de rament pas trop
- migrer la base vers un autre système mais la je perds tous les formulaires de maj et les tables importées de fichiers excel.
- garder le frontend Access et stocker les données sur un autre système. Ca semble la meilleure solution mais est-ce possible ?

Aaaaaaaaah je fooooooooooonds !

J'espère que vous pourrez m'aider.

BigFoot

[Tofalu]

Jamais deux utilisateurs ne doivent ouvrir le même fichier access.
Ils ouvrent un frontend situé sur leur poste qui interroge le backend situé sur le serveur. Pour ce qui est du web ... access n'est pas du tout fait pour cela

[keita]

salut
BigFoot69 a écrit:

1. Combien de connexions simultanées peut gérer Access (comprenez: sans ralentissement excessif)

en théorie 255.

1.b. en connexion web via php/odbc ?

perso, suis en train d'essayer (depuis peu, je l'avoue) un truc php-access
des sites l'ont reussi; je te trouverai un lien, d'ici peu.d'ici là, va voir ici:
http://aspn.activestate.com/ASPN/Coo.../Recipe/163447
@+

[BigFoot69]

Jamais deux utilisateurs ne doivent ouvrir le même fichier access.
Ils ouvrent un frontend situé sur leur poste qui interroge le backend situé sur le serveur.

Euh, concrètement, les utilisateurs vont sur le server et double click sur le .mdb.
Comment faire autrement ?

perso, suis en train d'essayer (depuis peu, je l'avoue) un truc php-access
des sites l'ont reussi; je te trouverai un lien, d'ici peu.

J'ai réussi à faire du php-access mais le problème c'est que, apparemment, le serveur Apache doit être sur la même machine que la base. Je n'ai pas encore trouvé de moyen d'accéder à une base access distante.

[stéphane_ais2]

Euh, concrètement, les utilisateurs vont sur le server et double click sur le .mdb.
Comment faire autrement ?

Bonjour,

Menu\Outils\Utilitaires de base de données\Fractionner une base de données :
- back = données sur le serveur
- front = appli sur chaque poste

SE

[BigFoot69]

Menu\Outils\Utilitaires de base de données\Fractionner une base de données :
- back = données sur le serveur
- front = appli sur chaque poste

Je viens d'essayer et ça m'a créé un fichier _be.mdb
Je suppose que be=backend, il est à peine moins gros que le fichier original.
Par contre je pige pas ce qui joue le role du frontend.
Le fichier original n'a pas changé.

Comprend pas

BigFoot

[stéphane_ais2]

effectivement, deux fichiers sont crées : les deux sont des fichiers .mdb ;
l'un contient les données (les tables) ; l'autre la partie appli (frm, rqt, état, code, etc.) ;
les tables sont liées à la partie appli par le biais du gestionnaire de tables liées ;
les données sont sur le serveur (Back ou dorsale) ; l'appli sur chaque poste...

SE

[BigFoot69]

Arg !

En fait j'ai compris l'astuce !!

Il n'y a pas 2 fichiers de créés mais bien un seul, mais le fichier d'origine est modifié !

En fait la taille du fichier d'origine affichait toujours la même chose car il faut compacter/réparer la base de données pour voir la taille réelle du fichier, soit ~2Mo

Autrement dit : IMPEC

Finalement je compte me diriger vers une solution batarde :
- la DB en mode frontend/backend pour la modification
- et un acces ASP pour la consultation (j'ai pas trouvé pour la connexion à un DB Access distante en PHP => problème avec le DSN).

J'espère qu'au niveau perf cela ne va pas poser de problème...

[stéphane_ais2]

Arg !

En fait j'ai compris l'astuce !!

Il n'y a pas 2 fichiers de créés mais bien un seul, mais le fichier d'origine est modifié !

Etonnant, puisque fractionner consiste à scinder la base originale en deux fichiers .mdb :
- données ou dorsale ou back-end
- base d'origine avec objets sauf les tables qui apparaissent liées et ne faisant plus partie du fichier .mdb frontal

SE

[BigFoot69]

La base est bien scindée en 2 comme suit:
- 1 fichiers créé base_be.mdb
- le fichier d'origine base.mdb est modifié et ne comporte plus que les liens etc

C'est pour cela qu'il est important de faire un backup de la base avant de split !!