Discussion :

[caporal]

Bonjour,

je vais vous décrire le mode de fonctionnement de nos bases de données, j'aimerai votre avis.


Toutes nos bases de données sont stockées sur le serveur.
Les utilisateurs se connectent sur les bases de données dans lesquelles ils trouvent les tables, les requetes, les formulaires, les états, grosso modo tout le toutim.
Jusqu'ici ca allait encore, car nous sommes une petite boite.

Suite à différents projets, nous avons été amené à lier créer des tables liées entre les différentes bases de données. Et à créer les requêtes et les formulaires et sous formulaires (utilisant ces tables liées) qui vont avec.

J'ajoute à cela que bien entendu il y a toujours plusieurs utilisateurs sur toutes les bases.


Ex de Pb rencontré, plus en détail:

J'ai un utilisateur qui se connecte à sa base de données sur le serveur.
La base utilise 9 tables liées et seulement une seule propre à elle-même.
Ce matin il a ouvert un formulaire utilisant ces 9 + 1 tables et il me dit qu'il a attendu 30 min. C'est peut être exagéré mais c'est très ennuyeux....

Sur ces 9 tables liées, il n'y en a qu'un qui soit tres grosse avec plein de champs; les 8 autres ne comportent que 2 champs avec une dizaine d enregistrements chacun.



J'ai trouvé des propositions d'améliorations sur ces liens suivants:

http://officesystem.access.free.fr/optimisation.htm

http://groups.google.ca/group/microsoft.public.fr.access/msg/5c83ceb63f4f6933?q=tables+li%C3%A9es+r%C3%A9seau+access&hl=fr&lr=lang_fr&ie=UTF-8&oe=UTF-8&rnum=1


A cela:

je me demande si il ne faudrait pas séparer les tables , qui resteraient sur le serveur, des requetes, formulaires et états, qui seraient sur les machines locales, et qui utiliseraient les tables liées. C'est quelquechose dont j'ai quelquefois entendu parler.

Quelles implications cela aurait il?

Est ce que la performance qui serait gagné par le pauvre utilisateur qui attend 30 minutes, ne se ferait pas au détriment de ceux qui utilisent la base qui contient physiquement les 9 tables, par ex?

Est ce qu'on gagne rééllement en performance, en ouvrant un formulaire local qui utilise une table sur le serveur, ou en utilisant une requete locale avec une table qui serait sur le serveur?

Est ce que j'aurai intéret à mettre toutes mes tables dans une seule et même base de données sur le serveur pour optimiser au mieux, ou est il envisageable d'utiliser plusieurs bases de données avec plusieurs tables sur le serveur, sans que les performances soient dégradées?

Avez vous d'autres idées d'implications?


Un grand merci pour vos réponses



Patrice

[stéphane_ais2]

Bonjour,

Toutes nos bases de données sont stockées sur le serveur.
Les utilisateurs se connectent sur les bases de données dans lesquelles ils trouvent les tables, les requetes, les formulaires, les états, grosso modo tout le toutim.

Peut-être qu'il faut penser à séparer la partie applicative (frm, rqt, état, etc...) de la partie données en utilisant l'assistant d'access dédié à cela pour obtenir :
-base dorsale (données) sur serveur
-base frontale (application) sur machines clientes

Si les besoins ont évolué, peut-être que la structure des données définies au début n'est plus adaptée...?
Est-ce que les utilisateurs ont les mêmes besoins d'accès aux informations?

...une somme de questions
à mon avis...

SE

[Julien Dufour]

Un petit retour d'expérience malheureuse.

J'avais une base contenant beaucoup de données. Du coup, les requêtes étaient relativement longues à tourner mais celà restait acceptable, environ une dizaine de secondes.
Le jour ou plusieures personnes ont eu besoin d'accéder à ces données j'ai scindé la base en deux : tables d'un côté et le reste sur l'autre.
Résultat : les mêmes requêtes mettaient parfois plus de cinq minutes pour tourner. Comme elles sont lancées plusieurs fois à la suite (recherche récursive des opérations foireuses) il a fallu que je revienne en arrière pour éviter que l'appli soit abandonnée.

Je ne sais pas si d'autres ont noté le même phénomène, mais moi ça m'a refroidi.

[stéphane_ais2]

J'ai retrouvé ce post enfoui dans mes archives qu'il est peut être utile de lire :
http://www.developpez.net/forums/vie...=r%E9seau+lent

...

SE

[caporal]

Bonjour,

nous avons appliqué les solutions suivantes et le résultat dépasse toute attente: le formulaire s'ouvre en quelques secondes!




*****************************************
ce qui a fonctionné pour moi (mais pour internet,
faudra adapter ):
la base front end, lorsqu'elle tente d'accéder à la base
backend (tables liées à un fichier source), rencontre un
fichier lockFile (*.ldb)
Access tente alors de supprimer ce fichier, mais n'y
parvient pas (puisque quelqu'un est déjà connecté sur la
base source). Après une quinzaine de tentatives,
infructueuses, Access renvoie enfin le jeu
d'enregistrement. Pour éviter cela, voilà ce que j'ai mis
en place:
afin d'établir une connection permanente avec la base en
backend, et donc de prévenir ce probème, créez

-un formulaire, appelons-le "frmdummy" (formulaire
stupide )
- une table "tbldummy" (avec un champ simple, n'importe
quel format, n'importe quel nom)
-dans un module standard, déclarez une variable globale
de type recordset
ex: Public rsAlwaysOpen As
Recordset
-Dans l'évènement sur ouverture du formulaire frmdummy
(OnOpen), ouvrez un recordset
Private Sub Form_Open(Cancel As Integer)
Set rsAlwaysOpen = CurrentDb.OpenRecordset
("DummyTable")
End Sub

-Dans l'évènement sur fermeture du formulaire frmdummy
(OnClose), fermez le recordset
Private Sub Form_Close()
rsAlwaysOpen.Close
Set rsAlwaysOpen = Nothing
End Sub

- au lancement de la db, ouvrez ce formulaire en premier,
avec visible=false
ce formulaire restera ouvert jusqu'à la fermeture de
l'appli.

Résultat: un traitement de 5 à 10X plus rapide ...
********************************************
dans les tables, passer en mode création, afficher les
propriétés des tables, et régler la propriété Sous
feuille de données (sub data sheet je crois) sur [Aucun]
([none])
Access a tendance à rapatrier toutes les "sous-
données" (tables en relations un à plusieurs en
général) , ce qui alourdit considérablement le trafic
d'infos dans les tuyaux
****************************************************
- toujours dans les tables, mais aussi dans l'appli:
Outils/Options/onglet général .. s'assurer d'avoir
décoché l'option "suivi correction automatique des noms"
(attention, il est possible que certains états perdent
leur mise en forme) .. conséquence, certains états
peuvent s'ouvrir jusqu'à 4 fois plus vite (merci
Microsoft)
*********************************************