Discussion :

[elgordopresto]

Bonjour à tous,

Voilà, j'ai une base de données métier qui tourne sur Access et qui est utilisée par une cinquantaine de personnes.

Je l'ai conçu progressivement en intégrant des fonctionnalités au fil du temps. Au départ, il n'y avait qu'une seule BDD contenant les données ainsi que les formulaires destinés aux utilisateurs.

Récemment, pour des questions de sécurité et de simplicité (je ne pouvais modifier un formulaire tant que quelqu'un était sur un formulaire...), j'ai décidé de dissocier les données des formulaires en adoptant une structure de type Frontale/Dorsale.

Je n'ai pas eu de souci particulier pour cette opération mais, en revanche, depuis cette manipulation, je constate des temps de réponse beaucoup plus lent qu'avant. A titre d'illustration, au lancement de la base les utilisateurs doivent saisir un identifiant et un mot de passe personnels, la validation était quasi-instantanée avant. Depuis la modification, il peut s'écouler 5 à 10 secondes parfois.

Y a-t-il un moyen d'optimiser les performances sur ce type de BDD ?

Merci par avance pour votre aide.

Bien cordialement.
el

[pyloupylou]

comment as tu fais pour répartir tes données entre dorsale et frontale ?
ou est installée la frontale ?
comment la base est sécurisée , avec un workgroup ?

[marot_r]

Bonjour,

Oui cela se produit parfois et il n'y a pas de recette mircale.

Est-ce que ta frontale est copiée sur chaque poste ou partagée sur le réseau ?

Si partagée, voit ce que cela donne avec une copie en locale.

Sinon, tu peux essayer de maintenir une table ouverte en permanance (ex : un formulaire caché branché sur cette table).

Après tu peux avancer formulaire par formulaire en faisant la chasse aux listes déroulantes, aux listes et éventuellement au sous-formulaire.

À l'ouverture Access charge les données pour alimenter les contrôles et cela peut lui prendre pas mal de temps. Dans ce cas, ne pas mettre de données au moment du chargement et n'aller les chercher qu'au moment où tu en a réellement besoin. Ça prend autant de temps au final mais comme c'est "découpé" en demandes plus petites cela se voit moins.

A+

[elgordopresto]

Bonjour et merci pour ces réponses,

@pyloupylou : je n'ai pas utilisé la fonction intégrée de Access (Fractionner une base de données). Je suis parti de zéro comme si je concevais la BDD pour la première fois. Bref, j'ai créé une bdd où j'ai mis toutes mes tables. J'ai créé une deuxième BDD où j'ai créé tous les formulaires et où j'ai créé les liaisons vers les tables de la BDD dorsale.
Ce n'est peut-être pas la meilleure méthode...

@marot_r : la frontale est sur le serveur et je sais que ce n'est pas l'idéal mais l'installation sur le poste de tous les utilisateurs me paraît trop complexe à mettre en oeuvre dans ma société. Il faudrait en plus la réinstaller à chaque fois qu'il y a une mise à jour de la frontale (nouvelles fonctionnalités, correction...).
J'ai par ailleurs fait le test avec une base que j'ai effectivement en local (c'est ma version d'homolo qui me permet de faire des modification en test) et j'ai les mêmes lenteurs. Pour l'exemple de la connexion, il n'y a rien de chargé, la seule chose que la base vérifie c'est, 1/ est-ce que l'identifiant saisi existe dans la table des identifiants et 2/ est-ce que le mot de passe correspond bien à celui qui est associé à cet identifiant ? Les deux tables sont très petites (une centaines de lignes max).
Est-ce que la structure frontale/dorsale mobilise plus de ressources serveurs ?
Je ne comprends pas bien le point sur la table ouverte en permanence, peux tu préciser ce que tu entends exactement pour que je puisse tester ? Avec tous mes remerciements.

[RobiPMS]

Bonjour.

Des pistes et des suggestions dans ce très complet tutoriel de Fabrice Constans.

Cordialement

[elgordopresto]

Merci !
Je vais regarder cela très attentivement.

[marot_r]

Je ne comprends pas bien le point sur la table ouverte en permanence, peux tu préciser ce que tu entends exactement pour que je puisse tester ?

Il semblerai que de garder une connexion ouverte sur une table en permamence aide à résoudre ce problème. Une façon simple de garder cette connexion ouverte est de le faire avec un formulaire que tu ouvres au lancement de ton appli. Le cacher fait que les utilisateurs ne le voient pas mais Access sait qu'il est ouvert.

Pour la copie en locale, vérifie quand même si cela améliore les choses. Après il y a des méthodes assez simples pour faire le déploiment sur n postes.

J'ai déjà eu une appli sur 50 postes répartis un peu partout à Montréal (40 x 20 km) et je ne courrais pas partout pour faire les installations :-).

Bonne chasse au bug.

A+

[pyloupylou]

Trés bonne années à vous tous

c'est les interactions entre le programme access et le fichier ldb de verrouillage avec des ouvertures et fermetures successives, à chaque fois que tu ouvres ou ferme une table qui peuvent provoquer des ralentissements. Le fait d'ouvrir une table et de conserver la liaison sur cette dernière pendant la durée de la session, empêche que la connexion sur le ldb soit fermée

Sinon je suis d'accord avec Marot_r, il est assez simple de:
- vérifier au lancement de l'application si une nouvelle version est disponible ( en comparant le numéro de version stocké en local sur la frontale , avec la version stockée dans la dorsale )
- de construire dynamiquement un .bat , de lancer ce point bat via un shell et de quitter access
- le point bat lui, fait une pause pour attendre la fermeture d'access, copie la dorsale de référence (stockée sur le serveur ) en local et relance l'application.

[elgordopresto]

Merci à tous pour ces précieux conseils et bonne année 2015 !

Je commence à être convaincu pour le déploiement local. Avez-vous éventuellement des ressources à me recommander sur le site pour commencer à m'y mettre, je pense notamment au .bat (je ne sais pas trop comment faire pour ce type de fichier).

J'ai également mis en oeuvre quelques uns des conseils qui sont contenus dans le lien proposé par RobiPMS

Bien cordialement.
el

[elgordopresto]

Bingo !

J'ai mis en place le principe du formulaire et de la table ouverts en permanence durant la session et ça marche. J'ai une petite lenteur au démarrage de la base mais après, dans la navigation sur l'appli, c'est beaucoup plus fluide.

Du coup, j'ai également compris pourquoi çà ramait... Je pensais naïvement que le fait d'ouvrir la frontale ouvrait automatiquement la dorsale mais en fait cela ne l'ouvre que si nécessaire (quand on appelle une table via la frontale) et du coup on se prend le temps de latence de l'ouverte du fichier, qui est assez volumineux dans mon cas.

Merci à tous pour votre aide très précieuse et je passe cette demande en résolue.

Bien cordialement.
el